SQL Server并行GROUP BY卡住主因是内存授予不足、数据倾斜或执行计划退化；应查GrantedMemory_KB与UsedMemory_KB是否接近、统计信息是否过期、索引顺序是否匹配“过滤→分组”逻辑，并用OPTION(MIN_GRANT_PERCENT=25,MAXDOP=2)保底内存、UNION ALL拆分热键、建正确覆盖索引。
GROUP BY 并行聚合卡住，大概率不是并行没开，而是内存分不够、数据倾斜或执行计划退化——索引再好也救不了。
查清是否真在并行，还是假并行拖慢
SQL Server 的并行 GROUP BY 不是“开了 MAXDOP 就加速”，它依赖查询内存授予（query memory grant）和实际数据分布。执行计划里看到 Parallelism 箭头，不代表真高效；常见假并行现象包括：
- Hash Match (Aggregate) 上方带红色警告：Warning: Operator used tempdb → 实际已降级为磁盘哈希，比单线程还慢
- GrantedMemory_KB 远小于 UsedMemory_KB（查 XML 执行计划或
sys.dm_exec_query_memory_grants）→ 内存不足，被迫刷出到 tempdb - Actual Rows 和 Estimated Rows 相差 10 倍以上 → 统计信息过期，优化器误判基数，选错并行阈值
实操建议：先跑 SET STATISTICS XML ON + 查询，搜 GrantedMemory_KB 和 UsedMemory_KB；再用 UPDATE STATISTICS dbo.YourTable WITH FULLSCAN 更新关键大表统计信息。
控制并行度与内存保底，别信默认值
SQL Server 2019 默认按成本阈值自动决定是否并行，但 GROUP BY 类查询常因估算偏差被“低估”，导致内存分太少、并行线程争抢严重。手动干预更稳：
- 用
OPTION (MIN_GRANT_PERCENT = 25, MAXDOP = 2)强制保底内存，避免小查询挤占大查询资源 -
MAXDOP = 2或4比MAXDOP = 0更可靠：并行度越高，每个 worker 分到的哈希桶越碎，缓存局部性越差，反而增加同步开销 - 禁用
QUERYTRACEON 8649：这是未公开 trace flag，2019+ 版本易污染 plan cache，且行为不可控
示例：SELECT o.CustomerID, SUM(o.Amount) FROM Orders o WHERE o.OrderDate >= '2024-01-01' GROUP BY o.CustomerID OPTION (MIN_GRANT_PERCENT = 30, MAXDOP = 2);
识别并绕过数据倾斜，别让一个 key 卡死全部线程
并行 GROUP BY 最怕倾斜——比如 95% 订单集中在 CustomerID = 1001，所有线程都得等这个 key 归并完成。这时 CPU 利用率可能只有 20%，却耗时几十秒。
- 快速定位倾斜键：
SELECT TOP 5 COUNT(*) c, CustomerID FROM Orders GROUP BY CustomerID ORDER BY c DESC - 对已知热 key 单独处理：用
UNION ALL拆分，例如先查WHERE CustomerID != 1001并行聚合，再补WHERE CustomerID = 1001单线程聚合 - 避免在 GROUP BY 中混用高基数 + 低基数字段（如
GROUP BY Country, UserID），若 Country 只有 5 个值，UserID 千万级，索引和并行效率都会被拉垮
索引必须匹配“过滤→分组”顺序，否则并行无意义
即使开了并行、调了内存，如果索引不支持流式分组（stream aggregate），SQL Server 仍要先排序或建哈希桶——并行只是把慢操作放大了 N 倍。
- 索引字段顺序必须是：WHERE 条件列（高选择性优先）→ GROUP BY 列（严格顺序一致）→ INCLUDE 聚合列
- 错误示例：
WHERE OrderDate > '2024-01-01'+GROUP BY CustomerID, Status，却建了(CustomerID, Status, OrderDate) INCLUDE (Amount)→ OrderDate 不在最左，WHERE 无法走索引范围扫描 - 正确写法：
CREATE INDEX IX_Orders_Date_CustomerID_Incl ON Orders (OrderDate, CustomerID) INCLUDE (Amount);→ 扫描天然有序，直接流式分组，无需 Sort 或 Hash Match
真正难的不是加并行开关，而是让数据物理顺序和逻辑分组顺序对齐——这点漏掉，所有内存和 DOP 调优都是白忙。
