sql server中group by并行计划常退化为串行，因优化器仅在能生成parallel hash aggregate算子时启用并行；一旦分组键含函数、统计信息过期致估算行数偏低10倍以上，或group by与order by字段不一致破坏数据局部性，即强制降级为串行stream/sort aggregate。

为什么GROUP BY的并行计划常退化为串行

SQL Server 对 GROUP BY 启用并行执行的前提很苛刻：它不看数据量大小，而看优化器是否能生成“可并行哈希分组”（Parallel Hash Aggregate）算子。一旦估算行数严重偏低、内存授予不足、或分组键存在隐式转换/排序依赖，优化器就会主动放弃并行，降级为串行 Stream Aggregate 或 Sort + Aggregate。这不是 bug，是保守决策——宁可慢一点，也不愿因并行线程争抢内存导致查询失败。

常见触发串行化的三个硬条件

以下情况只要出现一个，并行计划基本就凉了：

• GROUP BY字段含函数或表达式（如 GROUP BY YEAR(order_date)），优化器无法预估分组基数，倾向选串行 + 排序路径
• 统计信息过期，Estimated Number of Rows 比实际低 10 倍以上，优化器误判“小数据量”，直接跳过并行阈值检查
• 查询中混用 ORDER BY 且与 GROUP BY 字段不一致（如 GROUP BY user_id 却 ORDER BY created_at DESC），强制引入全局排序，破坏并行分组的数据局部性

MAXDOP 和内存设置如何反而禁用并行

很多人以为加 OPTION (MAXDOP 0) 就能强制并行，结果发现执行计划里还是串行 Aggregate。原因在于：

Upload audio to AIOZ Stream

快速上传音频至 AIOZ Stream API。支持默认或自定义编码配置创建音频对象，上传文件并完成处理后返回音频链接。

下载

• MAXDOP 0 只放开并行度上限，不保证启用并行；若优化器判定“并行开销 > 收益”，仍会选串行
• 内存授予不足时，即使 MAXDOP 允许并行，SQL Server 也会在运行时把并行线程逐个 kill 掉，回退到单线程执行——你看到的“串行计划”其实是运行时降级结果
• MIN_GRANT_PERCENT 设太高（比如 70），会导致查询排队等待内存，等真正拿到资源时，优化器已按串行路径重编译

怎么确认是不是并行真被禁用了

别只看执行计划图形界面里有没有并行图标，重点查 XML 执行计划里的两个节点：

• 找 RelOp NodeId="X" PhysicalOp="Hash Match Aggregate" 下是否有 Parallel="true"
• 搜 QueryPlan DegreeOfParallelism 属性值是否 > 1；若为 0 或 1，说明并行未启用
• 配合 sys.dm_exec_query_stats 查 execution_count 和 total_elapsed_time，如果同一条语句多次执行，degree_of_parallelism 列忽高忽低，说明内存竞争导致运行时抖动

最容易被忽略的是：并行失效往往不是孤立事件，而是和 tempdb 竞争、统计信息陈旧、以及查询参数嗅探三者叠加的结果。单点调优很难见效，得一起看。