关于SQL Server中的并行聚合，一个核心要点是：查询优化器会自动判断是否采用并行执行，无需手动启用。真正影响并行决策的关键参数是MAXDOP和cost threshold for parallelism。只有正确配置这两个参数，大型聚合查询才有可能真正使用并行计划。

为什么GROUP BY查询未能使用并行？

一个典型场景：执行SELECT COUNT(*), region FROM sales GROUP BY region时，执行计划中始终看不到Parallelism运算符，即使服务器拥有16核CPU。问题不在于语法，而是查询的预估成本未达到并行阈值。

• cost threshold for parallelism的默认值为5，即只有预估成本≥5的查询才会被纳入并行考虑。对于小表或经过筛选后数据量较小的聚合，其成本通常低于此阈值。
• 若统计信息过期或缺失，将导致成本估算不准确，优化器因此可能避免选择并行计划。
• 如果实例级MAXDOP设置为1（这在OLTP环境中很常见），则所有查询都将被强制串行执行，即使成本再高也无法使用并行。

如何确认并行聚合是否生效？

仅凭执行计划中是否存在Parallelism图标并不足够，需要按照以下步骤验证实际行为：

• 在查询前使用SET STATISTICS XML ON，然后在生成的XML执行计划中搜索或任何包含Parallel="1"的节点。
• 查询sys.dm_exec_query_stats和sys.dm_exec_query_plan，从query_plan字段解析是否包含。
• 在运行过程中观察sys.dm_os_tasks：对于同一个session_id，如果看到多个task_state = 'RUNNING'且context_switches_count显著增长，则表明线程已进入并行调度状态。

如何安全地提升并行聚合效率？

切勿直接设置MAXDOP = 0或cost threshold for parallelism = 1，这可能会拖垮OLTP场景。正确的做法是根据负载类型分层处理：

• OLAP/报表库：采用数据库范围配置，例如ALTER DATABASE [reportdb] SET MAXDOP = 8，同时降低阈值ALTER DATABASE SCOPED CONFIGURATION SET COST_THRESHOLD_FOR_PARALLELISM = 2。
• 混合型系统：保持实例级MAXDOP = 4，对于明确的大聚合语句，使用查询提示OPTION (MAXDOP 6)，避免影响其他事务。
• 务必同步更新统计信息：UPDATE STATISTICS sales WITH FULLSCAN, NORECOMPUTE，否则优化器仍会依据旧的数据分布估算成本。
• 关注CXPACKET等待：如果该等待占总等待比例超过30%，表明并行线程间存在严重倾斜或同步瓶颈。此时应检查GROUP BY列的数据分布是否极度不均（例如99%的值均为NULL）。

容易被忽视的聚合并行陷阱

许多DBA调整参数后却发现效果不明显，问题往往出现在以下细节上：

• 若GROUP BY列包含大量重复值（例如状态字段仅有3个取值），Hash Match并行分区后各线程处理的数据量差异巨大，导致部分线程空转等待，此时并行反而更慢。
• 如果在聚合时搭配了ORDER BY（例如GROUP BY x ORDER BY COUNT(*) DESC），排序操作可能成为串行瓶颈。即使聚合本身实现了并行，最终的Merge阶段仍以单线程运行。
• 临时表或CTE中的聚合，若未添加OPTION (RECOMPILE)，优化器可能重用旧计划，完全忽略当前数据量的变化。
• Azure SQL数据库默认MAXDOP = 8，且不允许修改实例级配置，只能通过数据库范围配置或查询提示进行覆盖。