MySQL的ORDER BY能走索引当且仅当排序字段构成索引的连续最左前缀，且未被函数、表达式或类型转换干扰；否则触发Using filesort。

MySQL 的 ORDER BY 能否走索引，关键看排序字段是否匹配索引的最左前缀，并且没有被函数、表达式或类型转换干扰。如果满足条件，MySQL 可直接利用索引的有序性避免额外排序（即 Using filesort），显著提升性能。

ORDER BY 走索引的核心前提

只有当排序列构成索引的**连续最左前缀**时，索引才能用于排序。例如有联合索引 (a, b, c)：

• ORDER BY a ✅ 可用
• ORDER BY a, b ✅ 可用
• ORDER BY a, b, c ✅ 可用
• ORDER BY a, c ❌ 不可用（跳过 b，中断最左前缀）
• ORDER BY b ❌ 不可用（未包含首列 a）

WHERE + ORDER BY 组合时的索引复用

当查询同时含 WHERE 和 ORDER BY，理想情况是用同一个索引兼顾过滤与排序。索引顺序应优先满足 WHERE 条件的等值列，再接排序列。

• 例如：查询 SELECT * FROM t WHERE status = 1 ORDER BY create_time
• 推荐建索引：(status, create_time)
• 这样既能快速定位 status = 1 的行，又能直接按 create_time 有序返回，无需排序
• 若只建 (create_time)，虽能排序，但 WHERE 过滤需全索引扫描；若只建 (status)，则排序仍要 filesort

避免破坏索引排序能力的操作

以下写法会让 MySQL 放弃使用索引做排序，强制执行 filesort：

• 对排序字段使用函数：ORDER BY UPPER(name)、ORDER BY YEAR(create_time)
• 混合 ASC/DESC：ORDER BY a ASC, b DESC（除非索引本身定义为 (a ASC, b DESC)，且 MySQL 8.0+ 支持）
• 排序字段和 WHERE 字段类型不一致导致隐式转换，如 WHERE user_id = '123'（user_id 是 INT），可能使索引失效并连带影响后续排序
• SELECT 中出现不在索引中的字段，且没有覆盖索引，虽不影响排序是否走索引，但会降低整体效率

验证是否真正用了索引排序

务必用 EXPLAIN 检查执行计划：

• 关注 type 是否为 range/ref 等高效访问类型
• 重点看 Extra 列：没有 “Using filesort” 才表示排序走索引
• 若出现 Using index，说明是覆盖索引，性能更优
• 注意：即使 key 显示用了某个索引，若 Extra 仍有 “Using filesort”，说明该索引仅用于查找，排序仍额外进行