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。原因在于：
-
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 竞争、统计信息陈旧、以及查询参数嗅探三者叠加的结果。单点调优很难见效，得一起看。
