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”，说明该索引仅用于查找，排序仍额外进行
否为 
