SQL查询中，ORDER BY子句用于返回有序结果集，当查询涉及大量数据排序时，如果没有合适的索引支撑，数据库往往需要执行额外的排序操作，甚至触发全表扫描，这会大幅拖慢查询响应速度。想要让排序和索引高效协同，就需要掌握ORDER BY的索引匹配策略。
ORDER BY索引匹配的核心前提
要让ORDER BY能够使用索引完成排序，首先需要满足一个基础条件：ORDER BY子句引用的列，必须是索引的最左前缀部分，或者整个ORDER BY的列顺序和索引定义的列顺序完全一致。如果索引是复合索引，那么ORDER BY的列顺序不能跳过索引中的前列，也不能打乱顺序。
基础匹配规则示例
假设我们有一张用户表，结构如下：
-- 创建用户表
CREATE TABLE user_info (
id INT PRIMARY KEY AUTO_INCREMENT,
age INT,
name VARCHAR(50),
create_time DATETIME,
INDEX idx_age_name_time (age, name, create_time)
);
上面的idx_age_name_time是复合索引，包含age、name、create_time三个列，顺序是age在前，name居中，create_time最后。下面看几种ORDER BY的匹配情况：
- ORDER BY age：匹配索引最左前缀，可以使用索引排序
- ORDER BY age, name：和索引前两列顺序一致，可以使用索引排序
- ORDER BY age, name, create_time：和索引所有列顺序一致，可以使用索引排序
- ORDER BY name：跳过索引最左列的age，无法匹配索引，需要额外排序
- ORDER BY age, create_time：跳过中间的name列，无法匹配索引，需要额外排序
- ORDER BY name, age：顺序和索引定义的顺序不一致，无法匹配索引，需要额外排序
排序方向与索引的匹配要求
除了列的顺序，ORDER BY的排序方向也会影响索引匹配。如果复合索引的所有列都是升序排序，那么ORDER BY子句的所有列也必须是升序，才能匹配索引。如果索引中存在降序定义的列，那么ORDER BY的对应列也需要是降序，才能使用索引排序。
还是以上面的idx_age_name_time索引为例，默认复合索引所有列都是升序，下面的ORDER BY可以匹配索引：
-- 全部升序，匹配索引 SELECT * FROM user_info ORDER BY age ASC, name ASC, create_time ASC; -- 默认升序，省略ASC也可以匹配 SELECT * FROM user_info ORDER BY age, name, create_time;
如果ORDER BY中出现了降序，就无法匹配这个默认升序的索引：
-- 最后一列降序，和索引方向不一致，无法匹配 SELECT * FROM user_info ORDER BY age, name, create_time DESC;
如果需要支持这种降序场景，可以创建对应方向的复合索引：
-- 创建支持前两列升序、最后一列降序的索引 CREATE INDEX idx_age_name_time_desc ON user_info (age ASC, name ASC, create_time DESC);
WHERE条件对索引匹配的影响
如果查询中同时存在WHERE条件和ORDER BY子句，那么WHERE条件中使用的索引列，会成为ORDER BY匹配索引的基础。此时ORDER BY的列需要是WHERE条件使用的索引列之后的连续列，才能继续匹配索引完成排序。
还是基于user_info表和idx_age_name_time索引，看以下场景：
-- WHERE使用了索引最左列age，ORDER BY接后面的name，匹配索引 SELECT * FROM user_info WHERE age = 20 ORDER BY name; -- WHERE使用了age和name，ORDER BY接后面的create_time，匹配索引 SELECT * FROM user_info WHERE age = 20 AND name = '张三' ORDER BY create_time; -- WHERE使用了age，ORDER BY跳过name直接接create_time，无法匹配索引 SELECT * FROM user_info WHERE age = 20 ORDER BY create_time;
如果WHERE条件中使用了范围查询（比如>、<、BETWEEN、LIKE前缀匹配等），那么ORDER BY的列如果不在范围查询列的后面，就无法继续匹配索引排序。因为范围查询之后的索引列会失效，ORDER BY自然也无法使用。
-- age是范围查询，后面的name和create_time索引失效，ORDER BY无法匹配索引 SELECT * FROM user_info WHERE age > 20 ORDER BY name;
常见不匹配场景与优化方法
场景1：ORDER BY列不在索引中
如果ORDER BY的列没有被任何索引覆盖，那么数据库需要对查询结果进行额外排序，也就是filesort操作。优化方法是为ORDER BY的列创建合适的索引，或者把ORDER BY的列加入到已有的复合索引中，注意顺序要符合匹配规则。
场景2：SELECT列导致索引失效
如果查询的SELECT列包含了索引之外的列，而索引不是覆盖索引，那么数据库可能需要回表查询，此时ORDER BY可能无法使用索引排序。优化方法是创建覆盖索引，把SELECT用到的所有列都加入到索引中，让查询可以直接从索引中获取所有数据，不需要回表。
场景3：排序方向不一致
如果业务需要部分列升序、部分列降序的排序，而现有索引都是同方向的，那么ORDER BY无法匹配索引。优化方法是创建对应排序方向的复合索引，比如需要ORDER BY age ASC, create_time DESC，就创建(age ASC, create_time DESC)的索引。
验证索引匹配情况的方法
可以通过EXPLAIN命令查看查询的执行计划，判断ORDER BY是否使用了索引排序。如果执行计划的Extra列中没有出现Using filesort，说明ORDER BY使用了索引排序；如果出现Using filesort，说明ORDER BY没有匹配索引，执行了额外排序操作。
-- 查看查询执行计划 EXPLAIN SELECT * FROM user_info WHERE age = 20 ORDER BY name;
执行上面的命令后，查看结果中的Extra字段，如果没有Using filesort，就说明当前的ORDER BY匹配了idx_age_name_time索引，排序操作由索引完成，性能较好。