SQL Server 2019中GROUP BY未走批模式，是因为未满足批处理硬性条件：兼容级别需≥150、分组列有有效统计信息、避免函数包裹（如DATEPART）、禁用大对象类型与OR谓词、索引顺序须严格匹配GROUP BY字段，且需通过执行计划ActualExecutionMode验证。
GROUP BY 为什么没走批模式？
SQL Server 2019 的 GROUP BY 并不自动变快，核心提速依赖「批模式执行（Batch Mode on Rowstore）」，但这个优化极易被绕过。执行计划里 Aggregate 节点的 ActualExecutionMode 显示 Row 而不是 Batch，就说明没触发。
常见拦路虎包括：
-
GROUP BY DATEPART(year, create_time)—— 函数包裹直接废掉批模式 -
SELECT中包含NVARCHAR(MAX)、TEXT或未压缩的XML字段，强制降级为行模式 -
WHERE条件用了OR且没加括号，导致谓词无法下推，中间结果集膨胀 - 聚合前连接顺序混乱，比如先
JOIN大宽表再分组，数据流无法对齐批处理粒度
索引怎么建才真正覆盖 GROUP BY？
不是所有索引都管用，必须满足「顺序一致 + 覆盖必要字段」两个硬条件。否则即使建了索引，GROUP BY 仍要回表或排序。
实操建议：
- 索引列顺序必须和
GROUP BY字段完全一致，例如GROUP BY region, product_category, status→ 索引应为(region, product_category, status) -
WHERE条件字段必须前置，如WHERE status = 'active' GROUP BY dept_id→ 索引应为(status, dept_id)，而非单独(dept_id) - 把
SELECT中所有非聚合列用INCLUDE加进去，形成覆盖索引：例如CREATE INDEX IX_dept_salary ON Employees(dept) INCLUDE (salary)，这样SELECT dept, AVG(salary) FROM Employees GROUP BY dept就不用回表 - 避免在分组列上建单列索引后还多加无关列——索引越宽，维护成本越高，且未必提升性能
内存不够时 GROUP BY 卡住怎么办？
查询跑着不动，不是 CPU 满了，很可能是内存授予不足，哈希分组被迫刷到 tempdb。看执行计划里的 GrantedMemory_KB 和 UsedMemory_KB：如果后者接近前者，甚至出现 Memory Grant Warning，就是典型信号。
别碰 QUERYTRACEON 8649，它不稳定且污染 plan cache。改用可控方式：
- 加
OPTION (MIN_GRANT_PERCENT = 30, MAXDOP 2)—— 强制保底分配 30% 估算内存，MAXDOP 2避免并行碎片化内存 - 调服务器级参数：
sp_configure 'cost threshold for parallelism'默认是 5，OLAP 类GROUP BY建议设为 25–50，让优化器更愿意走并行+批模式 - 检查
tempdb是否多文件预分配（至少等于 CPU 核数），否则并发哈希溢出时争抢tempdb文件头成瓶颈 - 更新统计信息：
UPDATE STATISTICS dbo.YourTable WITH FULLSCAN，防止因行数估算偏差导致选错执行计划（比如该哈希却选了排序）
嵌套 CTE 后 GROUP BY 变慢，问题在哪？
外层 GROUP BY 突然变慢，大概率是 CTE 写法引发「重复分组」：你在第一个 CTE 里只做了部分聚合，后续又在外层对宽结果集再做一次 GROUP BY，而这张中间表已有百万行。
关键动作只有两个：
- 在**最早一个 CTE** 里就完成全部维度分组和聚合计算，例如
GROUP BY user_id, region同时算出COUNT(*), SUM(amount)，别留到最外层再SUM()或COUNT() - 绝对禁止在 CTE 中写
SELECT *—— 字段顺序一旦基表变更，cte2引用时列错位，可能让分组逻辑彻底跑偏
批模式、索引、内存、CTE 结构这四点，漏掉任何一环，GROUP BY 都可能从秒级退化到分钟级。尤其是批模式，它不声不响地生效，也悄无声息地失效——得靠执行计划里那个 ActualExecutionMode 才能确认它到底在不在。
