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）锁定可靠计划，而不是依赖某次“调优成功”的侥幸。