MySQL 5.7 排序慢的根本原因是未走索引导致 filesort + sort_buffer_size 不足，而非配置低；调大该参数反而加剧并发卡顿，优先应优化索引设计与查询写法。
MySQL 5.7 排序慢，核心原因不是“配置低”，而是排序没走索引 + sort_buffer_size 不够撑住中间结果 —— 单调大这个参数反而可能让并发查询更卡。
ORDER BY 没走索引就必然触发 filesort
只要 EXPLAIN 的 Extra 列出现 Using filesort，说明 MySQL 放弃了索引有序性，转而用内存或磁盘做通用排序。这不是配置能绕过去的，是执行计划层面的退化。
- 单字段
ORDER BY uid DESC在 MySQL 5.7 仍可用(uid)索引（后向扫描），但性能略差； - 多字段混合方向，比如
ORDER BY uid DESC, sid ASC，哪怕有(uid, sid)索引，也一定Using filesort—— 因为 5.7 不支持降序索引； - WHERE 条件用了函数、类型隐式转换、或者范围查询在前（如
WHERE status = ? AND created_at > ? ORDER BY id），都可能导致排序字段无法复用索引。
sort_buffer_size 调大 ≠ 排序变快，反而可能拖垮并发
sort_buffer_size 是每个连接独占的内存，不是全局共享池。设成 8M 看似爽，但 100 个并发连接就吃掉 800MB 内存，还可能触发 ptmalloc 分配区争用，导致线程卡在内存申请上。
- 先看监控：执行
SHOW STATUS LIKE 'Sort_merge_passes';，如果该值持续上升，说明频繁落盘合并，才是sort_buffer_size真正不够的信号； - 默认值（256KB–1MB）对中小结果集足够，盲目调到 4M+ 往往只让单条查询快几毫秒，却让整体 QPS 下降；
- 注意：该参数不能动态改所有已有连接，只对新连接生效；
SET SESSION sort_buffer_size = 2097152;可临时调高某条语句，比全局改更安全。
真正有效的组合拳：索引设计 + 查询精简 + 算法选型
MySQL 5.7 对 LIMIT 场景其实有优化机制，但得满足条件才能触发“优先级队列排序”（堆排序），避免全量排序。
- 确保
ORDER BY ... LIMIT N中的N明确且不大（比如LIMIT 50），否则优化器可能放弃堆排序； - 避免 SELECT *，只查必要字段 —— 字段越少，
sort_buffer能塞更多行，降低落盘概率； - 对高频排序场景建覆盖索引：比如常查
SELECT name, age FROM user WHERE city = ? ORDER BY age，就建INDEX idx_city_age (city, age, name)，让 WHERE + ORDER BY + SELECT 全部命中索引； - 大字段（TEXT/JSON）参与排序时，8.0.20+ 才默认启用优化，5.7 必须靠索引规避，否则极易因单行超
sort_buffer_size直接报错。
最易被忽略的一点：MySQL 5.7 的排序性能瓶颈，往往不在内存大小，而在索引是否能自然覆盖整个排序路径。加索引是治本，调 sort_buffer_size 是止痛，但止痛药吃多了，系统会过敏。
