SQL Server中GROUP BY子句顺序为何会影响查询性能？

问题场景 #

在SQL Server中执行查询时，发现GROUP BY子句的列顺序会让查询速度相差约6倍，涉及表的数据量如下：

• PAGOS表：90万+行
• CXC表：16万+行
• CLIENTES表：1.2万+行

耗时18秒的查询 #

SELECT C.CLAVE 
FROM CLIENTES C
JOIN CXC ON CXC.CLIENTE = C.CLAVE
LEFT JOIN PAGOS P ON P.CLIENTE = C.CLAVE
WHERE P.CLIENTE IS NULL
GROUP BY P.CLIENTE, C.CLAVE

耗时3秒的查询 #

SELECT C.CLAVE 
FROM CLIENTES C
JOIN CXC ON CXC.CLIENTE = C.CLAVE
LEFT JOIN PAGOS P ON P.CLIENTE = C.CLAVE
WHERE P.CLIENTE IS NULL
GROUP BY C.CLAVE, P.CLIENTE

补充说明 #

若不将P.CLIENTE纳入GROUP BY，查询耗时同样为18秒，与GROUP BY P.CLIENTE, C.CLAVE的情况一致。

核心疑问 #

为何GROUP BY顺序会导致如此大的性能差异？多数资料称GROUP BY顺序不影响性能，为何这个案例是例外？

原因分析 #

你的查询中WHERE P.CLIENTE IS NULL已经过滤出所有P.CLIENTE为NULL的行，所以GROUP BY中的P.CLIENTE本质是常量值（全为NULL），这是关键前提。此时GROUP BY的顺序直接影响了SQL Server优化器对聚合策略的选择：

1. 当GROUP BY顺序为P.CLIENTE, C.CLAVE时：
   优化器优先按无区分度的P.CLIENTE（全NULL）分组，无法利用有序数据的优势，只能选择Hash Aggregate（哈希聚合）。哈希聚合需要构建哈希表，处理大量数据时内存开销大，甚至可能溢出到磁盘，这就是耗时18秒的核心原因。
   当你不包含P.CLIENTE在GROUP BY中时，优化器同样会走哈希聚合的执行路径，所以耗时一致。

2. 当GROUP BY顺序为C.CLAVE, P.CLIENTE时：
   优化器优先按C.CLAVE分组，而C.CLAVE作为CLIENTES表的主键（通常带有聚集索引），在JOIN过程中数据已经天然按C.CLAVE有序排列。此时优化器会选择Stream Aggregate（流聚合），流聚合不需要构建哈希表，直接对有序数据逐行聚合，性能远高于哈希聚合，因此耗时仅3秒。

多数资料提到GROUP BY顺序不影响性能，是基于列的区分度相当、优化器能稳定选择最优策略的常规场景。但你的案例中，某一列是无区分度的常量，GROUP BY顺序干扰了优化器的策略选择，才出现了特殊的性能差异。

优化建议 #

既然P.CLIENTE在过滤后全为NULL，完全可以从GROUP BY中移除。同时可以用NOT EXISTS替代LEFT JOIN + IS NULL的逻辑，等价且更高效：

SELECT C.CLAVE 
FROM CLIENTES C
JOIN CXC ON CXC.CLIENTE = C.CLAVE
WHERE NOT EXISTS (
    SELECT 1 FROM PAGOS P 
    WHERE P.CLIENTE = C.CLAVE
)

这个写法避免了不必要的JOIN和GROUP BY，优化器更容易生成高效的执行计划。

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