字段类型选太大真会拖慢查询
是的，MySQL 字段类型选择直接影响性能，尤其在索引、排序、临时表和内存使用上。用
VARCHAR(500)存邮箱，或用
INT存状态码（实际只用 0/1/2），都会让索引变胖、Buffer Pool 缓存效率下降、JOIN 时比较变慢。
核心影响点：索引大小 → B+树层级变深 → 更多次磁盘 I/O；行长度变大 → 同一数据页存的行数减少 → 扫描更多页；隐式类型转换 → 索引失效。
TINYINT足够表示 0–100 的状态码，别用
INT； 手机号固定 11 位且不参与数学运算，用
CHAR(11)比
VARCHAR(11)更省 CPU（无长度头开销，且定长利于排序）； 时间戳优先用
TIMESTAMP（4 字节，带时区自动转换）或
INT UNSIGNED（存储 Unix 时间戳，比
DATETIME少 1 字节且可索引友好）； 枚举类字段（如性别、订单状态）尽量用
TINYINT+ 注释说明，别用
VARCHAR(10)或
ENUM（
ENUM在排序、ALTER TABLE 时易出兼容性问题）。
TEXT 和 BLOB 类型容易触发磁盘临时表
只要 SELECT 或 GROUP BY 中涉及
TEXT、
BLOB或超长
VARCHAR（超过
max_allowed_packet或
tmp_table_size限制），MySQL 就无法在内存中建临时表，强制落盘成
MyISAM临时表（即使你用的是 InnoDB 引擎），I/O 开销陡增。 避免在
ORDER BY或
GROUP BY字段上用
TEXT； 如果必须存长文本，把内容单独拆到附表，主表只留
TEXT的摘要或哈希值（如
SUBSTRING(content, 1, 200)或
MD5(content)）； 检查
SHOW STATUS LIKE 'Created_tmp%';，若
Created_tmp_disk_tables明显高于
Created_tmp_tables，大概率是字段类型或 SQL 写法触发了磁盘临时表。
数值类型带符号（SIGNED）可能引发隐式转换
当字段定义为
INT UNSIGNED，但 WHERE 条件里写了负数（如
WHERE id = -1），MySQL 会把 -1 转成极大正数（
18446744073709551615），导致查不到结果且无法走索引——这在应用层传参未校验时很隐蔽。 统一用
INT UNSIGNED表示主键、计数器等非负场景，但确保所有客户端代码传入值 ≥ 0； 对比操作中混用有符号/无符号字段（如
JOIN a.id = b.uid，a.id 是
INT，b.uid 是
INT UNSIGNED），会强制将有符号侧转为无符号，可能溢出； 用
EXPLAIN FORMAT=TRADITIONAL查看执行计划，若出现
type: ALL且
Extra里有
Using where; Using temporary; Using filesort，要回头检查字段类型是否一致。
JSON 类型不是万能替代方案
MySQL 5.7+ 的
JSON类型支持校验和路径查询，但它的存储开销比扁平化字段高约 2–3 倍，且 JSON 字段无法直接建普通索引（需靠生成列 + 函数索引），查询性能远低于原生类型。 仅当字段结构高度动态、且访问频次低时才考虑
JSON； 高频查询字段（如用户等级、设备类型）坚决不要塞进
JSON，哪怕它看起来“灵活”； 若必须用 JSON，用
STORED生成列提取关键字段并建索引，例如：
ALTER TABLE users ADD level TINYINT AS (json_extract(profile, '$.level')) STORED;再对
level建索引。 字段类型优化不是一次性动作，而要结合实际写入模式、查询语句、索引策略一起看。最容易被忽略的是：开发阶段用宽泛类型图省事，上线后数据量上来，才发现
VARCHAR(255)在联合索引里吃掉了 3 倍内存，而改字段又得锁表。
