Using filesort 表示 MySQL 无法利用索引有序性而必须额外排序；常见原因包括 ORDER BY 字段不在索引最左前缀、ASC/DESC 混用、函数/表达式排序、非驱动表字段排序或未覆盖索引。
为什么 ORDER BY 会触发 Using filesort？
MySQL 在执行 ORDER BY 时，如果无法直接利用索引完成排序，就会把结果集读入内存（或临时磁盘文件）再排序，这个过程就叫 Using filesort——注意它和“用文件排序”字面意思无关，而是 MySQL 内部的排序机制代号。真正触发它的常见原因有：
• 查询字段没被索引覆盖（比如 SELECT * 但索引只包含部分列）
• ORDER BY 的列顺序/方向与索引不一致（如索引是 (a, b ASC)，却写 ORDER BY a, b DESC）
• 对非索引列、函数或表达式排序（如 ORDER BY UPPER(name) 或 ORDER BY a + b）
• 使用了 JOIN，但排序字段来自驱动表之外的关联表，且无合适联合索引
如何改写 SQL 让 ORDER BY 走索引？
核心原则：让 ORDER BY 子句完全匹配某个可用索引的最左前缀，且不掺杂计算或类型转换。
• 如果查询只查几列，改 SELECT * 为显式列出字段，并确保这些字段都在同一个索引中（即走覆盖索引）
• 若需按 created_at DESC 排序，而现有索引是 (user_id, created_at)，那就补一个 (created_at) 单列索引，或重建为 (created_at DESC)（MySQL 8.0+ 支持降序索引）
• 多表 JOIN 场景下，优先把排序字段所在的表作为驱动表，或在被驱动表上为 ON + ORDER BY 字段建联合索引（例如 JOIN orders o ON u.id = o.user_id 且要 ORDER BY o.created_at，就在 orders(user_id, created_at) 建索引）
• 避免在 ORDER BY 中使用 CAST、CONVERT、DATE() 等函数；如必须按日期排序，提前在字段上建生成列并索引：ALTER TABLE t ADD COLUMN created_date DATE AS (DATE(created_at)) STORED，再对 created_date 建索引
LIMIT 能绕过 Using filesort 吗？
不能直接绕过，但能显著降低开销——MySQL 优化器在看到 LIMIT 时，可能选择“索引扫描 + 堆排序取 top-N”，而不是全量排序。不过前提是 ORDER BY 本身仍得走索引。
• ORDER BY indexed_col LIMIT 10：大概率走索引，不出现 Using filesort
• ORDER BY non_indexed_col LIMIT 10：仍会触发 Using filesort，只是只排前 10 行，代价小些
• 注意：如果 WHERE 条件筛选后结果极少，优化器可能干脆放弃索引排序，改走全表扫描 + 小数据量排序——这时加索引反而没用，得看 EXPLAIN 的 rows 和 Extra 字段综合判断
哪些“看似合理”的改写其实无效？
有些写法看起来更简洁或语义更清楚，但实际破坏索引利用：
• 把 ORDER BY a, b 改成 ORDER BY a ASC, b ASC：没问题，ASC 是默认值，不影响索引匹配
• 把 ORDER BY a DESC, b ASC 改成 ORDER BY a DESC, b DESC：如果索引是 (a DESC, b ASC)，后者反而不匹配
• 用子查询包装排序逻辑，如 SELECT * FROM (SELECT ... FROM t ORDER BY x) t1 LIMIT 10：MySQL 5.7 及以前会强制物化子查询，大概率引入 Using filesort；8.0+ 有优化，但仍不如直接在外层加索引可靠
• 用 UNION ALL 拼多个有序结果再整体排序：除非每个分支都严格走索引且合并逻辑简单，否则外层 ORDER BY 几乎必然触发 Using filesort
真正起作用的永远是索引结构与查询模式的对齐，而不是 SQL 表达形式上的“优雅”。检查执行计划时，盯紧 key 和 Extra 两列，比反复改写语句更有效。很多所谓“慢排序”，其实是 WHERE 条件没走索引导致回表太多，连带让排序成本飙升——这时候先解决过滤，排序自然就快了。
