避免 filesort 的关键是让 ORDER BY 走索引：为排序列建合适索引（注意最左前缀），WHERE 与 ORDER BY 结合时用复合索引，禁用非索引表达式，配合 LIMIT 使用有效索引，并通过 EXPLAIN 检查执行计划。
避免 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 事后补救。
