mysql中varchar长度过大拖慢查询的根源是内存预分配机制，而非磁盘空间：它导致排序、临时表和索引页“虚胖”，触发磁盘落盘或i/o爆炸；超768字节（utf8mb4下超191字符）还会引发行溢出，select *时强制读取溢出页造成额外随机i/o。
MySQL中VARCHAR长度设得过大，真正拖慢查询的不是磁盘空间，而是内存预分配机制——它会让排序、临时表、索引页全部“虚胖”，最终触发磁盘落盘或I/O爆炸。
临时表为什么会突然变慢？
MySQL在执行GROUP BY、ORDER BY、UNION等操作时，会把中间结果放进内存临时表。这时它不看字段实际存了几个字符，只认你定义的长度。
-
VARCHAR(255)在utf8mb4下按255 × 4 = 1020字节预分配，哪怕只存"a" -
VARCHAR(50)同理只占50 × 4 = 200字节 - 1万行数据就多占约8MB内存——这还没算并发连接和其它字段
- 一旦总大小超过
tmp_table_size和max_heap_table_size中较小的那个值，MySQL立刻把内存表转成磁盘表（MyISAM或InnoDB），性能断崖式下跌
查证方式：SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'; 如果这个值持续上涨，基本就是被大VARCHAR撑爆了。
为什么EXPLAIN显示走了索引，但查询还是慢？
索引本身能建成功，不代表高效。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字节的VARCHAR、TEXT、BLOB。这类字段会触发InnoDB「行溢出」：真实数据被挪到独立溢出页，主记录只留20字节指针。
- 哪怕你
SELECT *里根本不需要那个字段，MySQL仍会顺着指针去读溢出页——额外随机I/O - 常见现象：
EXPLAIN显示type=ALL，但执行时间远超预期；SHOW PROFILE里Handler_read_next次数异常高 - 注意：不是所有大VARCHAR都会溢出——只有单字段定义长度×字符集字节数 > 768时才触发（
utf8mb4下即>191字符）
所以VARCHAR(255)在utf8mb4下大概率溢出，而VARCHAR(191)刚好卡在边界内，这是很多团队没意识到的临界点。
真正容易被忽略的，不是“该不该设255”，而是没人定期跑SELECT MAX(LENGTH(email)) FROM users; —— 数据分布永远比设计规范更诚实。
