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