字段类型选太大真会拖慢查询，因索引变胖、数据页行数减少、隐式转换致索引失效；text/blob易触发磁盘临时表；int unsigned与有符号混用引发隐式转换；json性能差且难索引。
字段类型选太大真会拖慢查询
是的，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 倍内存，而改字段又得锁表。 
