GROUP BY慢主因是未匹配执行流的联合索引导致临时表（Worktable）和哈希聚合，需按WHERE→JOIN→GROUP BY顺序建索引并覆盖分组列与INCLUDE字段，同时确保批模式触发条件与内存授予合理。

GROUP BY慢是因为用了临时表，不是索引没建全

如果在执行计划里看到了 Worktable、Hash Match (Aggregate)，或者直接冒出警告 Operator used tempdb，基本就能判断：SQL Server 没办法沿着索引的天然顺序把分组做完。

这时它只能转到内存里处理，甚至落到磁盘上，临时搭一套结构来完成聚合。

这类情况，问题往往不在于“有没有建索引”，而在于索引和分组逻辑没有真正对齐。

举个典型例子：GROUP BY o.CustomerID, c.CustomerName, c.City，可现有索引却只覆盖了 CustomerID 这一列，那就很难顺着索引直接完成分组。

• 先跑 SET STATISTICS IO ON + 查询，看 logical reads 是否远超表行数。比如 5000 万行表读出 800 万页，大概率在扫临时结构。
• 别信“已有索引”。跨表多字段分组时，必须确保所有 GROUP BY 列都在同一联合索引里，且顺序与分组顺序一致。
• INCLUDE 字段要覆盖所有聚合用到的列。如 SUM(o.Amount) 就得把 Amount 加进 INCLUDE，否则仍会回表。

建什么索引才真正起作用

有效索引绝不是把“分组字段简单拼一串”就能解决。

真正要看的是查询执行时的先后顺序，也就是按 WHERE → JOIN → GROUP BY 这条链路来排布。

比如这类查询，先用 WHERE o.OrderDate BETWEEN @s AND @e AND o.Status IN ('Completed','Shipped') 做筛选，再去 JOIN Customers，最后才执行 GROUP BY o.CustomerID, c.CustomerName, c.City。

对应下来，最合适的索引应该是：

CREATE INDEX IX_Orders_DateStatus_CustomerID_Incl ON Orders (OrderDate, Status, CustomerID) INCLUDE (Amount);

• OrderDate 和 Status 放最前：让范围扫描尽早砍掉 90% 数据，减少后续分组输入量。
• CustomerID 紧跟其后：使扫描结果天然按分组键有序，避免额外 Sort。
• Customers 表上必须有 CustomerID 主键（已有），但 CustomerName 和 City 需单独建索引或加进 INCLUDE，否则 JOIN 后还得查。

别让批模式（Batch Mode）失效

SQL Server 2019 的 Batch Mode on Rowstore 能把 GROUP BY 速度提几倍，但它很娇气，不满足条件就会退化回低效的行模式。

执行计划里 Aggregate 运算符的 ActualExecutionMode 显示 Row，就是没触发。

• 中间结果集得 >10 万行，小查询不会启用批模式。
• 分组列不能套函数：GROUP BY DATEPART(year, create_time) 直接禁用批模式；改用 WHERE create_time >= '2024-01-01' + 原始列分组。
• SELECT 列里别塞 NVARCHAR(MAX)、TEXT 等大字段，它们会让引擎降级。
• 别乱加 OPTION (MAXDOP 0)。并行度太高反而打散批处理粒度；MAXDOP 2 或 4 更稳。

内存不够时 GROUP BY 就卡住，不是 CPU 问题

查询卡在 30 秒不动，大概率是哈希分组内存不足，开始往 tempdb 刷数据。

看执行计划里的 GrantedMemory_KB 和 UsedMemory_KB：如果后者接近前者，或者出现 Memory Grant Warning，就是内存瓶颈。

• 用 OPTION (MIN_GRANT_PERCENT = 30, MAXDOP 2) 强制保底内存，比瞎调 MAXDOP 可靠。
• MIN_GRANT_PERCENT 设太高（如 80）会导致其他查询排队，30–50 是较安全区间。
• 统计信息过期会让优化器低估行数，错选 Sort + Stream Aggregate 而非哈希——跑 UPDATE STATISTICS with FULLSCAN 再试。
• QUERYTRACEON 8649 是调试标记，2019+ 版本可能污染 plan cache，别用。

真正该盯的优化重点

真正的瓶颈往往藏在索引顺序、内存授予和批模式兼容性这三处。

而不是“再建个索引”或“加大服务器内存”这种模糊动作。

《夸克》非常好用的免费AI浏览器

下载APP查看