避免 MySQL 中的
filesort是提升
ORDER BY查询性能的关键。它本质上意味着 MySQL 无法利用索引完成排序，转而使用临时文件或内存进行额外排序，开销大、速度慢。核心思路是让排序操作“走索引”，而不是“绕开索引”。
确保 ORDER BY 字段被索引覆盖
最直接有效的方式：为
ORDER BY的列（或列组合）建立合适的索引。尤其注意联合索引的**最左前缀原则**： 如果查询是
ORDER BY a, b，索引
(a, b)可以完全支持；但
(b, a)或单独
(a)就不行（除非还带了
WHERE a = ?等等约束） 如果同时有
WHERE和
ORDER BY，优先考虑创建复合索引，把
WHERE条件列放前面，
ORDER BY列紧随其后。例如：
WHERE status = 'active' ORDER BY created_at DESC，建索引
(status, created_at)
避免在 ORDER BY 中使用非索引表达式
任何对排序字段做函数处理、计算或类型转换，都会导致索引失效，触发
filesort： ❌
ORDER BY UPPER(name)→ 即使
name有索引也不生效 ❌
ORDER BY created_at + INTERVAL 1 DAY❌
ORDER BY CONCAT(first_name, ' ', last_name)✅ 改用已索引的原始字段，或提前物化计算列并为其建索引（MySQL 5.7+ 支持生成列 + 索引）
限制结果集大小，配合索引使用 LIMIT
当
ORDER BY+
LIMIT同时出现，且能命中合适索引时，MySQL 可以用“索引扫描 + 提前终止”方式快速拿到前 N 条，极大减少排序量： 例如
SELECT * FROM orders ORDER BY id DESC LIMIT 20，若
id是主键或有索引，几乎不触发
filesort但若
ORDER BY create_time而
create_time没索引，即使加了
LIMIT，仍需先排全表再取前 20 —— 依然慢 所以
LIMIT本身不避免
filesort，必须和有效索引配合才起作用
检查执行计划，识别隐式排序陷阱
用
EXPLAIN查看
Extra列是否含
Using filesort。还要警惕一些看似无关却引发排序的操作：
GROUP BY默认会隐式
ORDER BY相同字段（MySQL 8.0 前），可加
ORDER BY NULL显式禁用 多表
JOIN后
ORDER BY非驱动表字段，容易走
filesort；尽量让排序字段来自驱动表，或为被驱动表字段建索引
SELECT DISTINCT在某些场景下也会引入额外排序，可考虑改用
GROUP BY+ 索引优化
不复杂但容易忽略。关键就是让排序逻辑落在索引结构上，而不是交给 MySQL 事后补救。
