MySQL排序优化核心是减少filesort，优先用索引覆盖排序（如(status,created_at,id)支持WHERE+ORDER BY），控制数据量、避免SELECT*、合理配置参数，并识别隐式排序陷阱。
MySQL 的排序性能优化核心在于减少 filesort，优先利用索引完成排序，避免临时表和磁盘 I/O。关键不是调大 sort_buffer_size，而是让查询“不用排”或“轻量排”。
用索引覆盖排序（最有效）
当 ORDER BY 字段有合适索引，且该索引还能覆盖 SELECT 中的列（或至少覆盖 WHERE + ORDER BY），MySQL 就能直接按索引顺序读取数据，跳过排序步骤。
- 例如：
SELECT id, name FROM users WHERE status = 1 ORDER BY created_at;，若存在联合索引(status, created_at, id)或(status, created_at, name)，即可避免 filesort - 注意最左前缀原则：
ORDER BY created_at单独出现时，索引(status, created_at)仍可用；但ORDER BY name就无法利用该索引 - 使用
EXPLAIN查看Extra列：没有Using filesort才算成功
控制排序数据量（降低开销）
即使触发了 filesort，只要参与排序的行数少、字段短、内存足，性能依然可控。重点是避免全表排序。
- 加有效的
WHERE条件缩小结果集，比单纯建索引更立竿见影 - 避免
SELECT *，只查必要字段——尤其别带大字段（如TEXT、BLOB），否则会强制使用rowid排序模式，额外回表，显著拖慢 - 如果必须排序大量数据，考虑在应用层分页时用“游标分页”（如
WHERE created_at > 'xxx' ORDER BY created_at LIMIT 20），避免OFFSET越大越慢
合理配置排序相关参数
参数调优是辅助手段，不能替代索引设计，但在高并发小排序场景下可提升稳定性。
-
sort_buffer_size：每个连接独享，非全局总和。设太大易引发内存争抢，建议单值 256K–2M，根据平均排序行数微调 -
max_length_for_sort_data：控制 MySQL 选择“双路排序”还是“单路排序”。值设太小会导致频繁回表；设太大可能内存溢出转磁盘。默认 1024 通常合理，除非明确知道排序字段总长远小于它 -
read_rnd_buffer_size：配合 sort_buffer 使用，影响回表随机读效率，一般无需调整，默认值足够
识别并避开隐式排序陷阱
某些写法看似没排序，实则触发 filesort，容易被忽略。
-
GROUP BY默认附带ORDER BY，如不需要结果有序，显式加上ORDER BY NULL -
UNION结果集默认去重+排序，如无需排序，用UNION ALL - 对函数或表达式排序，如
ORDER BY UPPER(name)，无法使用普通索引，需建立函数索引（MySQL 8.0+）或生成列索引
不复杂但容易忽略：先看执行计划，再想索引，最后调参数。多数慢排序问题，一个合适的联合索引就能解决 80%。
