ORDER BY能否走索引取决于WHERE条件、select字段与索引的最左前缀匹配：等值查询后接排序列可走索引，范围查询或跳过最左列则失效；覆盖索引可避免回表和filesort；NULL值和混合排序方向也影响索引使用。
ORDER BY 走不走索引，看 WHERE 和 SELECT 之后的字段
sql 查询中 ORDER BY 是否能用上索引，不只取决于排序字段本身有没有索引，更关键的是它和 WHERE 条件、SELECT 列是否构成“最左前缀匹配”。
比如表上有联合索引 (a, b, c)：
-
WHERE a = 1 ORDER BY b→ 可走索引（a等值，b用于排序） -
WHERE a > 1 ORDER BY b→b无法用于排序（范围查询后，后续列不能保证有序） -
WHERE b = 1 ORDER BY c→ 不走索引（跳过最左列a，索引失效） -
SELECT * FROM t WHERE a = 1 ORDER BY b→ 若*包含未覆盖字段，可能触发回表；但排序仍可用索引
ORDER BY + LIMIT 组合容易误判执行计划
加了 LIMIT 后，优化器可能更倾向走索引排序，哪怕代价略高——因为它能早停。但反过来，如果 ORDER BY 字段没索引，又带 LIMIT，mysql 仍得全表扫描+文件排序，性能陡降。
常见陷阱：
- 误以为
LIMIT 10就一定快：若没索引支撑排序，它只是在内存或磁盘排序完再截取前 10 行 - 用
EXPLaiN看Extra字段：using filesort是危险信号；Using index才说明排序直接走索引 - 复合排序如
ORDER BY a ASC, b DESC，需确认索引定义是否匹配方向（MySQL 8.0+ 支持降序索引，5.7 及以前一律升序存储）
覆盖索引对排序效率的影响被低估
当索引包含 WHERE 条件列 + ORDER BY 列 + SELECT 所需列时，就构成覆盖索引。此时不仅排序快，连回表都省了。
例如查询 SELECT id, name FROM users WHERE status = 1 ORDER BY created_at：
- 索引
(status, created_at, id, name)可完全覆盖——无回表、无 filesort - 索引
(status, created_at)仅支持排序和过滤，仍要回表取id和name，且排序后还得按主键捞数据 - 注意字段顺序：
created_at必须紧跟在等值条件列之后，才能用于排序
NULL 值和排序方向会破坏索引有效性
MySQL 索引中 NULL 值默认排在最前（升序）或最后（降序），但具体行为受 sql_mode 和版本影响。更麻烦的是，一旦 ORDER BY 字段允许 NULL，且查询里没显式过滤，优化器可能放弃使用该索引排序。
实操建议：
- 排序字段尽量设为
NOT NULL，避免隐式类型转换或空值干扰 - 如果业务允许，用
WHERE col IS NOT NULL显式排除，有时能帮优化器选对索引 - 混合排序方向（如
ORDER BY a ASC, b DESC）在老版本 MySQL 中必然导致Using filesort，除非建专门的降序索引
真正卡住性能的，往往不是没建索引，而是建了但没对上 WHERE + ORDER BY + SELECT 这三者的组合逻辑。调优时先看 EXPLAIN 的 key 和 Extra，再反推索引结构是否匹配实际查询模式。