SQL Server 2022 不支持强制使用 Stream Aggregate 的 Hint；它仅在输入已按 GROUP BY 列严格排序时由优化器自动选择，依赖索引顺序、无函数/隐式转换、禁用并行等条件提升出现概率，并需通过实际执行计划中 PhysicalOp="Stream Aggregate" 确认。
SQL Server 2022 不支持强制使用“流聚合”（Stream Aggregate）运算符的 Hint 或配置项。 它没有类似 OPTION (HASH GROUP) 或 OPTION (MERGE JOIN) 那样的 STREAM AGGREGATE 提示，也没有开关能“开启流式聚合模式”。所谓“流聚合”，是查询优化器在生成物理执行计划时，基于输入是否已按 GROUP BY 列排序、内存压力、基数估算等条件自动选择的一种物理运算符——它不是用户可调度的执行策略，而是结果。
为什么你看到的执行计划里没有 Stream Aggregate？
Stream Aggregate 要求上游数据**已经按 GROUP BY 表达式严格排序**（升序或降序均可），否则无法逐行归并累加。常见导致缺失的原因包括：
- GROUP BY 列上缺少合适索引，或索引顺序不匹配（例如索引是
(a, b)，但查询写的是GROUP BY b, a） - 查询中混用了聚合与非确定性函数（如
GETDATE()、NEWID()），破坏了排序可推导性 - 存在隐式转换（如
WHERE id = '123'对 int 列），导致索引查找后无法保证输出顺序 - 并行度开启且优化器判定 Hash Aggregate 更稳（尤其在大基数场景下）
如何提高 Stream Aggregate 出现概率？
核心思路是“给优化器一条清晰、低成本的有序路径”：
- 为
GROUP BY列创建**覆盖型聚集索引或非聚集索引**，确保键顺序与分组列完全一致（含方向），例如：CREATE INDEX IX_orders_status_date ON dbo.orders (status, order_date) - 避免在分组字段上做函数操作，如
GROUP BY YEAR(order_date)会断掉索引顺序；改用计算列+索引或范围预处理 - 显式添加
ORDER BY子句（即使业务逻辑不需要），只要和GROUP BY列相同且方向一致，可能触发排序+流聚合组合，例如：GROUP BY status ORDER BY status - 用
OPTION (MAXDOP 1)临时禁用并行，减少优化器对 Hash Aggregate 的偏好（仅用于验证，勿长期使用）
如何确认是否真走了 Stream Aggregate？
别只看“Aggregate”文字描述——必须打开实际执行计划（SET STATISTICS XML ON），在图形计划中找图标为“∑”且属性 PhysicalOp="Stream Aggregate" 的节点。注意区分：
-
Hash Aggregate：有“Build”和“Probe”阶段，常伴随高内存授予（GrantedMemory） -
Stream Aggregate：无内存申请，节点右侧通常连着“Index Scan”或“Index Seek + Sort”（Sort 是危险信号，说明上游没排好） -
Compute Scalar后跟Stream Aggregate是常见健康组合，说明表达式未破坏排序流
真正难的不是让 Stream Aggregate 出现，而是让它稳定出现——一旦统计信息过期、参数嗅探偏差或并发负载变化，优化器就可能换回 Hash。所以线上关键聚合查询，建议配合查询存储（Query Store）锁定可靠计划，而不是依赖某次“调优成功”的侥幸。
