ORDER BY 能否走索引取决于最左前缀匹配、无函数/表达式干扰、类型一致三点；满足时可避免 filesort，需结合 EXPLAIN 的 Extra 列（是否含 Using filesort）判断。
MySQL 的 ORDER BY 能否走索引，关键不在于有没有索引，而在于查询条件和排序字段是否满足最左前缀匹配 + 无计算/函数干扰 + 类型一致这三点。
哪些情况 ORDER BY 可以直接用上索引
当 ORDER BY 字段是某个已建索引的最左连续部分，且没有被表达式、函数或类型转换“破坏”，就能避免文件排序（Using filesort）。
- 有联合索引
idx_a_b_c(a,b,c)，查询WHERE a = 1 ORDER BY b, c→ ✅ 走索引 - 同上索引，
WHERE a = 1 AND b > 2 ORDER BY c→ ✅ 走索引（范围查询后还能用等值字段排序） -
WHERE b = 2 ORDER BY b→ ❌ 不走索引（跳过了最左列a） -
ORDER BY ABS(c)或ORDER BY UPPER(name)→ ❌ 索引失效（函数导致无法直接比较）
如何判断是否真的用了索引排序
别只看 EXPLAIN 里有没有 key 字段，重点看 Extra 列：
- 出现
Using filesort→ 没走索引排序，MySQL 在内存或磁盘临时排序 - 没出现
Using filesort，且key显示用了某个索引 → ✅ 排序走索引 - 如果
type是index或range，同时Extra为空或只有Using index→ 大概率是索引覆盖+有序扫描
常见但容易踩的坑
很多优化建议只说“加索引”，却忽略了实际使用场景的限制：
-
SELECT * FROM t ORDER BY created_at DESC LIMIT 10→ 即使created_at有单列索引，也可能因回表代价高被优化器放弃，改用全表扫描+filesort -
WHERE status IN (1,2) ORDER BY create_time→IN对非唯一字段可能让排序索引失效（尤其数据分布不均时） - 字符串字段用
utf8mb4_bin和utf8mb4_0900_as_cs排序行为不同，隐式转换（如数字 vs 字符串比较）会导致索引失效 - 多表 JOIN 后
ORDER BY，必须确保排序字段属于驱动表，且该表的排序字段上有合适索引
实用优化建议
不是所有排序都必须强求索引，但可以按优先级操作：
- 先确认慢查询是否真卡在排序：用
SHOW PROFILE或 Performance Schema 查Sorting result耗时 - 对高频分页查询（如
ORDER BY id LIMIT 10000,20），优先考虑游标分页（WHERE id > ? ORDER BY id LIMIT 20） - 若排序字段固定且查询条件简单，建联合索引时把排序字段放在最后（如
WHERE a=1 AND b IN (1,2) ORDER BY c→ 建idx_a_b_c(a,b,c)） - 对大字段（如
TEXT）参与排序，考虑生成摘要列（如md5(content)）并为其建索引，再配合冗余更新维护一致性
