SQL Server 2022中GROUP BY慢的主因是分组字段未有效走索引或被WHERE函数等操作破坏索引使用；应通过执行计划确认是否Index Scan、建覆盖索引、用WHERE提前过滤、慎用OR和HAVING，并优先考虑DISTINCT替代无聚合的GROUP BY。
GROUP BY慢，先看执行计划里有没有索引扫描
SQL Server 2022中GROUP BY慢的最常见原因是：分组字段没走索引，或者走了索引但被其他操作“拖垮”了。比如你在WHERE子句里对分组字段用了函数（如YEAR(order_time)），哪怕该列有索引，也会强制全表扫描。
实操建议：
- 用
SET STATISTICS IO ON和SET STATISTICS TIME ON跑一遍查询，重点关注logical reads和elapsed time - 打开执行计划（Ctrl+M），检查
GROUP BY对应的Hash Match (Aggregate)或Stream Aggregate上游是不是Index Scan——如果是，说明没走索引查找（Seek） - 确认分组字段是否在索引的最左前缀上；复合索引
(user_id, order_time)能加速GROUP BY user_id，但不能加速GROUP BY order_time
用WHERE提前过滤，别让GROUP BY处理冗余数据
GROUP BY的性能和输入行数强相关。10万行分组比1万行慢得多，不是因为分组逻辑变复杂了，而是中间结果集膨胀了。
实操建议：
- 把时间范围、状态码等高选择性过滤条件写在
WHERE里，而不是靠HAVING——HAVING是在分组后才执行的，此时已经完成聚合计算 - 避免在
WHERE里用OR连接多个条件，尤其是跨不同索引路径时，容易导致优化器放弃使用索引 - 如果业务允许，加个
TOP N限制输出（如SELECT TOP 100 ... GROUP BY ...），有时能触发更优的流式聚合计划
替代方案：DISTINCT有时比GROUP BY快得多
当需求只是“按某几列去重”，而不是做SUM、COUNT等聚合计算时，SELECT DISTINCT在SQL Server 2022里往往比GROUP BY快一个数量级。这不是错觉，是执行引擎内部实现差异导致的。
实操建议：
- 确认你真需要聚合函数。如果只是
SELECT col1, col2 FROM t GROUP BY col1, col2，直接换成SELECT DISTINCT col1, col2 FROM t - 注意
DISTINCT和GROUP BY语义不完全等价：前者只去重，后者可带聚合；但如果你没写聚合函数，优化器其实也只做了去重 - 测试时别只看第一次执行时间——清空缓存（
DBCC DROPCLEANBUFFERS; DBCC FREEPROCCACHE;）再测，避免缓存干扰判断
小表驱动+覆盖索引，让Stream Aggregate成为可能
SQL Server倾向用Stream Aggregate（流式聚合）代替Hash Match（哈希聚合），前提是输入数据已按分组字段排序。而排序成本很高，所以最好让索引直接提供有序数据。
实操建议：
- 为
GROUP BY字段建**覆盖索引**，把SELECT中所有非聚合列都包含进去。例如：CREATE INDEX IX_orders_user_status ON orders(user_id, status) INCLUDE (order_time, amount) - 如果关联了小表（比如
JOIN一张只有几十行的配置表），把小表放FROM左侧，有助于优化器生成嵌套循环+流式聚合组合 - 避免在
SELECT列表里对索引列做计算或转换，比如UPPER(name)会破坏索引有序性，迫使改用Hash Match
Warnings图标和Estimated Subtree Cost数值，比任何经验口诀都更值得你多盯两眼。 
