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)）并为其建索引，再配合冗余更新维护一致性
