MySQL索引在ORDER BY中失效的核心原因是字段顺序不匹配最左前缀原则：索引(a,b,c)仅支持ORDER BY a、a,b或a,b,c等连续从左开始的排序，跳过中间列（如a,c）或起始不一致（如b）均触发Using filesort。
ORDER BY 字段顺序不匹配索引最左前缀，MySQL 无法复用索引天然顺序
MySQL 只能利用索引中「连续、从左到右」的字段顺序来满足排序需求。索引 (a, b, c) 的物理存储是先按 a 升序，a 相同时再按 b 升序，b 也相同时再按 c 升序。一旦 ORDER BY 跳过中间字段（如只写 ORDER BY a, c），或起始字段不一致（如 ORDER BY b），索引就无法提供有序输出——优化器只能回表取数据后额外排序，触发 Using filesort。
WHERE + ORDER BY 混合场景下，索引断裂直接导致排序失效
常见错误是建了 (status, created_at) 索引，但查询写成 WHERE status = 1 AND category = 'A' ORDER BY created_at。这里 category 不在索引中，MySQL 用不上 status 索引做范围扫描，更无法延续到 created_at 排序；即使 status 走了索引，category 条件迫使回表或全表过滤，后续 created_at 就彻底失去索引顺序保障。
- 索引必须覆盖所有
WHERE等值条件列 + 所有ORDER BY列，且顺序严格连续 - WHERE 中出现范围条件（如
created_at > '2023-01-01'）时，该字段右侧的索引列无法用于排序 -
EXPLAIN中key有值但Extra含Using filesort，基本可断定是索引被用于查找、但未用于排序
ASC/DESC 混用在旧版本 MySQL 中必然触发 filesort
MySQL 5.7 及之前完全不支持反向索引扫描。哪怕你建了 INDEX (user_id, pay_time DESC)，查询写 ORDER BY user_id ASC, pay_time DESC，优化器仍会忽略索引排序能力，走 filesort。MySQL 8.0.12+ 虽支持，但需确认两点：
- 建索引时显式声明
DESC（如CREATE INDEX idx ON t (a ASC, b DESC)） -
EXPLAIN的key显示用了该索引，且Extra不含Using filesort - 避免在
ORDER BY中对字段加函数，如ORDER BY UPPER(name)，索引值与计算值不等价，直接失效
SELECT * 和非覆盖查询让主键索引也白搭
很多人以为 ORDER BY id 天然走主键索引就不会 filesort，结果 EXPLAIN 里还是出现 Using filesort。根本原因是 SELECT * 导致必须回表取所有列，而回表是随机 I/O，拿到的数据顺序不再受主键约束——优化器只能把这批无序数据拉进 sort_buffer 重排。
- 换成
SELECT id, name, status，并建覆盖索引INDEX (status, id, name)，就能避免回表 - 索引列顺序必须是
WHERE条件列在前、ORDER BY列紧随其后，不能穿插无关字段 - 即使只查三个字段，如果索引是
(status, name, id)，而ORDER BY id，依然会filesort—— 因为id不在索引最右连续位置
真正卡住性能的，往往不是“有没有索引”，而是索引结构和查询字段顺序之间那几毫秒都容不得错配的严丝合缝。一个 EXPLAIN 里 Using filesort 的提示，背后大概率是索引定义漏掉了一个等值条件，或者 ORDER BY 多写了一个没在索引里的字段。
