MySQL中VARCHAR字段长度过大主要拖慢查询的三大隐性开销是内存预分配、索引页填充率下降和行存储结构膨胀。
MySQL中VARCHAR字段长度设得过大，真正拖慢查询的不是磁盘空间，而是内存预分配、索引页填充率和行存储结构这三处隐性开销。哪怕只存一个字符，VARCHAR(255)在utf8mb4下也会按1020字节预分配——这是性能下跌的起点。
临时表为什么突然变慢？
MySQL执行ORDER BY、GROUP BY或UNION时，会把中间结果放进内存临时表。它不看字段实际存了几个字符，只认你定义的长度。
-
VARCHAR(50)在utf8mb4下按50 × 4 = 200字节预分配 -
VARCHAR(255)则按255 × 4 = 1020字节预分配 - 1万行数据就多占约8MB内存——并发高时极易突破
tmp_table_size或max_heap_table_size限制 - 一旦溢出，MySQL立刻把内存表转成磁盘表（MyISAM或InnoDB），性能断崖式下跌
查证方式：SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';，如果该值持续上涨，基本就是被大VARCHAR撑爆了。
索引为什么走了却还是慢？
索引能建成功，不代表高效。InnoDB B+树索引页固定16KB，每页能存多少索引项，取决于单个索引项的长度。
-
VARCHAR(2000)字段即使只存10个字符，索引页仍要预留最坏情况的空间 - 结果是每页存的索引项变少 → 树高增加 → 查询需要更多I/O跳转
- 若该字段参与组合索引（如
(status, content)），content过长会让整个索引膨胀，反而不如只对status建单列索引 + 应用层过滤
验证方法：EXPLAIN SELECT * FROM logs WHERE content LIKE 'abc%';，先看key是否命中，再结合Rows_examined与Rows_sent比值判断是否回表过多。
SELECT * 变慢和行溢出有关吗？
有关，但只针对单字段定义长度 × 字符集字节数 > 768字节的情况（utf8mb4下即 > 191字符）。
- 超限后触发InnoDB「行溢出」：真实数据挪到独立溢出页，主记录只留20字节指针
- 哪怕
SELECT *里根本不需要那个字段，MySQL仍会顺着指针去读溢出页——额外随机I/O -
VARCHAR(255)在utf8mb4下大概率溢出；VARCHAR(191)刚好卡在边界内，这是很多团队没意识到的临界点
常见现象：EXPLAIN显示type=ALL，但执行时间远超预期；SHOW PROFILE里Handler_read_next次数异常高。
字段长度还影响页内密度和NULL位图
InnoDB页内组织变长字段时，会为每个VARCHAR预留长度数组空间，并用偏移指针跳转到值位置。字段上限越大，越倾向分配更宽松间隙：
- 长度数组本身可能从1字节升为2字节（当最大长度 ≥ 256）
- 多个大
VARCHAR并存时，指针位宽膨胀 + 值区碎片化，导致同一数据页能塞下的记录数明显下降 - 每行只要有一个
NULL列，InnoDB就得额外分配NULL位图（1字节管8列），且该位图位置固定，会整体后推后续字段偏移地址 - 字段越多、
NULL列越分散，偏移指针就越容易从1字节升为2字节，进一步挤占页内有效空间
查实际影响：SHOW TABLE STATUS LIKE 'table_name';对比Avg_row_length与各字段理论宽度之和（含NULL位图、长度数组、指针开销）。如果前者比后者高出一倍，基本坐实了这个问题。
