ORDER BY 用不上索引的典型现象是执行 EXPLAIN 时 Extra 列出现 Using filesort，说明MySQL未利用索引排序而是回表后额外排序；常见原因包括ORDER BY字段未被索引覆盖、SELECT *导致无法走覆盖索引、WHERE与ORDER BY字段不在同一索引或顺序冲突。
ORDER BY 用不上索引的典型现象
执行 EXPLAIN 看到 Extra 列出现 Using filesort，基本就说明 MySQL 没走索引做排序，而是回表后在内存或磁盘里额外排序。这不是“慢一点”的问题，是数据量一上去，性能断崖式下跌的信号。
常见诱因有三个：
-
ORDER BY字段没被包含在查询使用的索引里（哪怕只是多一个字段顺序不对） - 用了
SELECT *或非索引覆盖字段，导致无法走“覆盖索引 + 索引有序”路径 -
WHERE条件和ORDER BY字段不在同一个索引里，或顺序冲突（比如索引是(a, b)，却WHERE b = ? ORDER BY a）
怎么建索引让 ORDER BY 直接命中
核心原则：把 WHERE 等值条件字段放前面，ORDER BY 字段紧接其后，且保持升序/降序一致。MySQL 只能利用索引的最左前缀做排序，不能跳过中间字段。
例如查询：SELECT id, name FROM users WHERE status = 1 ORDER BY created_at DESC
应该建：ALTER TABLE users ADD INDEX idx_status_created (status, created_at DESC)
注意点：
- 如果
WHERE有多个等值条件（如status = 1 AND type = 'vip'），它们可以按任意顺序写进索引，但必须全在ORDER BY字段之前 - MySQL 8.0+ 支持对单个索引字段单独指定
ASC/DESC，但 5.7 及以前会忽略DESC声明，实际按升序存储；此时若强制ORDER BY ... DESC，可能仍触发Using filesort - 联合索引里一旦出现范围查询（
>,BETWEEN,LIKE 'abc%'），后面的字段就无法用于排序
为什么加了索引还是 Using filesort
不是所有“看起来能走索引”的排序都会被优化。最容易被忽略的是字段类型隐式转换和字符集不匹配。
比如：WHERE user_id = '123' ORDER BY updated_at，而 user_id 是 INT 类型 —— 字符串字面量触发隐式转换，导致索引失效，连带后面的 ORDER BY 也废掉。
还有几类硬伤：
-
ORDER BY包含函数或表达式，如ORDER BY UPPER(name)，索引字段必须是函数索引（MySQL 8.0+）且显式创建 - 查询中用了
UNION、子查询或DISTINCT，优化器可能放弃索引排序策略 - 索引字段为
NULL允许且数据中大量存在，某些版本下会影响排序路径选择
ORDER BY 和 LIMIT 联合时的坑
LIMIT 看似能“减少工作量”，但 MySQL 不会因为加了 LIMIT 10 就自动选更短的排序路径。它仍然要先完成全部排序，再截断 —— 除非整个排序过程能完全由索引满足。
所以这个组合才是真正的优化关键点：WHERE a = ? ORDER BY b LIMIT N。只要 (a, b) 有合适索引，MySQL 就能按索引顺序逐行取，找到 N 行就停，不用排全表。
但要注意：
- 如果
WHERE条件匹配出 100 万行，而你只想要前 10 行，没有对应索引的话，MySQL 仍会排序全部 100 万行，再取前 10 —— 这就是“小 limit 大代价” -
OFFSET越大越危险，比如LIMIT 10000, 10，即使有索引，也要先定位到第 10000 行，中间扫描不可跳过 - 用游标分页（
WHERE b > ? ORDER BY b LIMIT 10）比OFFSET更可靠，前提是b唯一或能处理重复值
真正难的不是建对索引，而是确认查询模式是否稳定 —— 字段值分布、参数变化、统计信息是否过期，都可能让优化器临时放弃你精心设计的索引。上线前一定要用真实数据量 EXPLAIN FORMAT=JSON 看执行计划，别信开发环境里的“快”。
