sql server中group by未走并行，主因是预估开销低于cost threshold for parallelism默认值5，或实例级maxdop被设为1；需结合更新统计信息、按负载类型调参（如olap设maxdop=8、阈值=2）并验证xml执行计划中parallel="1"节点。
并行聚合在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 执行计划，搜索<relop nodeid='.*?PhysicalOp="Hash' match .></relop>或类似带Parallel="1"的节点 - 查
sys.dm_exec_query_stats+sys.dm_exec_query_plan，用query_plan字段解析是否有<relop.></relop.> - 运行中观察
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且不可改实例级，只能靠数据库范围配置或查询提示覆盖
