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%。
