ORDER BY子句排序顺序是否会影响SQL查询的执行性能？

针对你提出的问题，查询A和查询B的性能存在明显差异，查询B的性能会优于查询A，核心原因是索引的有序性是否能被ORDER BY子句利用，具体分析如下：

1. 现有索引结构解析 #

你创建的过滤索引overlap_idx的结构为：

create index overlap_idx
  on originals (prefix, from_suffix, to_suffix, order_created_on desc)
  include (order_id)
  where latest = 1;

这个索引的有序逻辑是：

• 首先按prefix升序排列
• 相同prefix的行，按from_suffix升序排列
• 相同prefix+from_suffix的行，按to_suffix升序排列
• 最后按order_created_on降序排列

同时索引包含了查询所需的order_id，且过滤条件latest=1与索引的WHERE子句匹配，所以查询可以直接使用该索引（覆盖索引扫描）。

2. 查询B的ORDER BY与索引有序性匹配 #

查询B的排序逻辑是：

order by ori.prefix, ori.from_suffix, ori.order_created_on desc

结合查询的WHERE条件ori.prefix = ?，所有符合条件的行prefix值完全相同。此时ORDER BY的实际排序逻辑等价于from_suffix升序，再order_created_on降序——这和索引中prefix固定后的有序顺序完全一致。

因此数据库在扫描索引时，直接按索引的顺序读取数据即可得到符合排序要求的结果，不需要额外执行排序操作，性能最优。

3. 查询A的ORDER BY无法利用索引有序性 #

查询A的排序逻辑是：

order by ori.order_created_on desc, ori.prefix, ori.from_suffix

同样因为prefix是固定值，排序逻辑等价于先order_created_on降序，再from_suffix升序。但索引中prefix固定后的顺序是先from_suffix升序，再to_suffix升序，最后才是order_created_on降序，和查询A的排序要求不匹配。

这意味着数据库需要先从索引中取出所有符合WHERE条件的行，再对这些行执行额外的排序操作（比如SQL Server中的Sort运算符）。当结果集数据量较大时，这个排序步骤会显著增加查询的CPU和内存消耗，导致耗时变长。

4. 验证方法 #

你可以通过查看两个查询的执行计划来确认：

• 查询B的执行计划中不会出现Sort运算符
• 查询A的执行计划中会包含Sort运算符，且该运算符的成本占比会比较高

内容的提问来源于stack exchange，提问作者Ginkgochris