sql server 2022 聚合性能比 2019 有实质性提升，但仅在同时满足列存储索引、兼容级别160和query_store启用时生效；string_agg等新函数在列存+160下支持批处理，提速2–5倍，而2019不支持或降级为行模式。
SQL Server 2022 的聚合性能比 2019 有实质性提升，但这种提升不会自动发生——它只在你明确打开三把“钥匙”时才生效：列存储索引 + 兼容级别 160 + QUERY_STORE 启用。缺一不可。
STRING_AGG 等新函数在列存表上是否走批处理模式
这是最典型的分水岭场景。2019 对 STRING_AGG、JSON_OBJECT_AGG 等函数完全不支持批处理模式聚合，哪怕表是列存储，也会强制降级为行模式，甚至可能报错；2022 在列存表 + 兼容级别 160 下，这些函数能真正走批处理路径。
- 实测中，相同数据量下
STRING_AGG聚合耗时下降 2–5 倍 - 若表是行存储（哪怕加了普通索引），2019 和 2022 都只能走行模式，性能几乎无差别
- 检查是否启用批处理：查看执行计划中聚合运算符的
Actual Execution Mode是否为Batch
GROUP BY 高基数字符串列是否频繁 spill 到 tempdb
当 GROUP BY 列含大量唯一值（如用户 ID、URL、长文本）时，哈希聚合极易内存不足。2022 的批处理哈希聚合内存管理更稳，尤其配合内存授予反馈持久化后，spill 概率显著降低。
- 2019 的内存授予反馈仅对单次重编译有效，参数变化后立刻失效
- 2022 将反馈结果写入查询存储，后续执行自动复用，夜间大批次聚合不再突然 timeout
- 必须确保
QUERY_STORE开启且数据库兼容级别为160，否则反馈不持久
统计信息过期是否导致聚合估算严重偏差
聚合性能卡在“估算不准”上，比卡在“算得慢”更隐蔽。2022 引入统计双阈值机制，默认在数据变动达 10% 或 200 行（取小者）时触发更新，而 2019 仍依赖旧式固定阈值（20% + 500 行）。
- 典型症状：
Hash Warning: No space left in hash table在 2019 中反复出现，在 2022 中消失 - 该机制无需额外配置，但要求
auto update statistics为ON - 对实时宽表（高频插入后立即聚合）效果最明显，2019 容易低估分组数，分配内存不足
真正决定聚合快慢的，从来不是版本号本身，而是你有没有让 2022 的新执行路径“被看见”。列存储不是可选项，兼容级别 160 不是建议项，QUERY_STORE 更不是报表功能——它们是聚合优化的硬性前置条件。漏掉任意一个，就等于开着引擎盖却没点火。
