MySQL 5.7 大字段排序性能骤降的根本原因是单行大字段（如TEXT）超出sort_buffer_size导致强制磁盘filesort，且索引无法覆盖完整值，调大缓冲区或建前缀索引均无效，必须通过业务层规避（如冗余小字段、应用侧排序）。
MySQL 5.7 处理大字段（如 TEXT、JSON、长 VARCHAR）参与排序时性能骤降，根本原因不是“字段太大”，而是排序路径被迫退化为磁盘 filesort，且无法被 sort_buffer_size 缓解——因为单行数据就超出了缓冲区容量。
大字段导致 sort_buffer_size 直接失效
MySQL 5.7 的排序机制依赖 sort_buffer_size 装下「每行用于排序的字段总长度 × 行数」。一旦某一行的排序字段（比如一个 500KB 的 TEXT）本身已远超默认 sort_buffer_size（通常 256KB–1MB），MySQL 就会立即放弃内存排序，直接走磁盘 filesort，哪怕只排 10 行。
-
SELECT * FROM posts ORDER BY content DESC中content是TEXT字段 → 几乎必然触发磁盘排序 - 即使加了
WHERE id IN (1,2,3)限制 3 行，只要content单值 >sort_buffer_size，仍会落盘 -
SET SESSION sort_buffer_size = 8388608（8MB）对这种场景收效甚微：内存分配是 per-connection 独占，且大字段拷贝开销高，还可能引发ptmalloc分配争用
5.7 不支持覆盖索引绕过大字段
你可能会想：“建个联合索引把排序字段包进去不就行了？”但在 5.7 中，如果排序字段本身是大字段，索引就无法真正“覆盖”它：
- 索引项有 767 字节（utf8mb4 下为 3072 字节）长度限制，
TEXT字段只能前缀索引（如content(100)），但ORDER BY content需要完整值比对 → 索引失效 - 即便建了
INDEX idx_status_content (status, content(100))，WHERE status = ? ORDER BY content依然触发Using filesort - EXPLAIN 显示
key用了索引，但Extra仍有Using filesort—— 这说明索引只用于过滤，排序仍靠磁盘
为什么 8.0+ 能缓解而 5.7 不能？
这不是配置问题，是排序模型差异：
- MySQL 8.0.20+ 废弃了
max_length_for_sort_data，改用全字段内存排序策略，并对大字段引入了优化（如只缓存排序键 + 行指针），但 5.7 没有该机制 - 5.7 的
filesort在遇到大字段时，连“优先队列排序（堆排序）”都难触发，因为初始行加载阶段就溢出 - 升级到 8.0 后若未重建索引或调整查询，反而可能更慢 —— 因为 8.0 更严格暴露了原来靠隐式容忍撑住的问题
最容易被忽略的一点：在 MySQL 5.7 中，对大字段排序的优化，几乎只能靠业务层规避 —— 比如把排序逻辑移到应用侧、用冗余小字段（content_hash 或 content_length）替代、或预计算排序权重存入新列并建索引。硬调 sort_buffer_size 或加索引，在这里基本是无效动作。
