GROUP BY慢需查执行计划中Sort、Hash Match或TempDB溢出，核对预估与实际行数偏差，确保GROUP BY字段有顺序匹配的复合索引，避免函数导致全表扫描，WHERE过滤须前置且禁用函数。
GROUP BY执行慢，先看执行计划里有没有Using temporary; Using filesort
SQL Server 2019不会显示“Using temporary”这种MySQL风格的提示，但对应的是执行计划中出现Sort、Hash Match (Aggregate)或Spill To TempDB警告。只要看到TempDB被大量写入，基本就能断定分组过程被迫落盘——这是性能崩塌的起点。
真正要盯住的是Estimated Subtree Cost和Actual Number of Rows是否严重偏离。比如预估100行，实际扫描500万行，说明统计信息过期或索引失效，优化器选错了路径。
- 用
SET STATISTICS XML ON捕获执行计划，重点检查Hash Match节点的Warnings属性是否有Spill - 确认
GROUP BY字段上是否存在有效索引：必须是复合索引，且顺序与GROUP BY子句完全一致（如GROUP BY a, b, c→ 索引需为(a, b, c)，不能是(b, a, c)） - 避免在
GROUP BY中使用函数或表达式，例如GROUP BY YEAR(order_date)会强制全表扫描；改用计算列+索引：ALTER TABLE orders ADD order_year AS YEAR(order_date) PERSISTED，再建索引
WHERE过滤必须比GROUP BY早，且不能漏掉高选择性条件
很多人把过滤逻辑全堆在HAVING里，比如写HAVING COUNT(*) > 1 AND MAX(amount) > 10000，结果发现跑得比全表还慢。这是因为HAVING是在分组之后才执行，数据库已经把几百万行分好桶、算完聚合，才开始筛——白干了99%的计算。
真正该前置到WHERE里的，是能大幅缩小原始数据集的条件。比如订单表有1亿行，但你要查“2024年Q3的订单”，这个时间范围筛选应该放在WHERE，而不是等分组完再用HAVING卡。
-
WHERE中禁用函数：别写WHERE DATEPART(year, order_date) = 2024，改用WHERE order_date >= '2024-01-01' AND order_date - 如果业务允许，给高频过滤字段加
filtered index，例如只索引状态为'shipped'的订单：CREATE INDEX IX_orders_shipped ON orders(customer_id, amount) WHERE status = 'shipped' - 对大表做
GROUP BY前，先用TOP 10000验证逻辑是否正确，避免一跑就是半小时才发现SQL写错了
大数据量分组时，tmpdb和内存配置不是可选项，是必调项
SQL Server 2019默认的max server memory和tempdb文件数，面对千万级以上分组根本扛不住。一旦Hash Match需要的内存超过授予额度，就会立刻溢出到tempdb，而磁盘IO速度比内存慢两个数量级。
这不是调优技巧，是硬性资源门槛。我处理过一个日志表按user_id + event_type分组的案例，没调tempdb前跑27分钟，调完后压到38秒。
-
tempdb至少配置4个数据文件（不要1个），大小均等，启用Trace Flag 1117让所有文件自动等比例增长 - 确保
max server memory留足物理内存的70%以上给SQL Server，避免Windows系统内存不足触发tempdb暴涨 - 对超大分组查询，显式指定最小内存授予：
OPTION (MIN_GRANT_PERCENT = 30)，防止优化器低估内存需求
NULL值和重复键会悄悄拖垮GROUP BY效率
SQL Server把所有NULL值视为相同分组值，这本身没问题。但问题在于：如果GROUP BY字段上有大量NULL，会导致单个分组桶异常庞大，哈希算法退化成线性扫描，Hash Match性能断崖下跌。
另一个隐形杀手是重复键。比如按customer_id分组，但表里有10万个customer_id IS NULL的测试数据，这些全挤进同一组，聚合函数就得遍历10万次——而你可能根本不需要它们。
- 在
WHERE里提前排除无意义的NULL：WHERE customer_id IS NOT NULL，别指望HAVING来救 - 如果业务允许，用
COALESCE(customer_id, -1)替代NULL，并确保该值在业务中不真实存在，避免影响语义 - 检查分组字段的基数（distinct count / total rows），若低于0.1%，说明该字段不适合单独做
GROUP BY主键，考虑先用WHERE缩小范围再分组
GROUP BY跑得慢，八成不是SQL写得不对，而是你还没看清那几百万行数据到底长什么样。 
