多列group by卡顿主因是内存grant不足或哈希分组退化，应查执行计划中grantedmemory_kb与usedmemory_kb是否接近/超限，确认是否触发磁盘哈希；优先用min_grant_percent和适配maxdop调控内存，而非盲目建索引。
直接结论：多列 GROUP BY 卡住，90% 是内存 grant 不足或哈希分组退化，不是索引没建好，也不是 SQL 写错了。
查执行计划里的 GrantedMemory_KB 和 UsedMemory_KB
别靠猜，用 SET STATISTICS XML ON 跑一次查询，然后在 XML 执行计划里搜索这两个字段。如果 UsedMemory_KB 接近或超过 GrantedMemory_KB，说明 SQL Server 已开始把哈希桶刷到 tempdb；出现 Warning: Memory Grant Warning 就是明确信号——已降级为磁盘哈希，性能断崖下跌。
- 用
sys.dm_exec_query_memory_grants查正在跑的查询：重点关注grant_time为空（等内存中）、required_memory_kb远大于granted_memory_kb的记录 - 别用
DBCC MEMORYSTATUS：它反映的是实例级缓冲池，和单个查询的内存 grant 完全无关 - 多列 GROUP BY 会显著增加哈希表内存估算值，尤其是当列组合基数高、字符串列长、或含
varchar(max)时，估算容易严重偏低
加 OPTION (MIN_GRANT_PERCENT = x, MAXDOP n) 控制内存分配
SQL Server 2016+ 支持显式干预内存 grant，比盲目开 MAXDOP 0 更可控。对多列 GROUP BY，MIN_GRANT_PERCENT 是硬保底，不是建议值。
- 设
MIN_GRANT_PERCENT = 25到40比较稳妥；设太高（如 80）会导致其他并发查询排队等待 -
MAXDOP必须配合调：多列哈希对并行度更敏感，MAXDOP 2或4往往比0更快——线程越多，每个线程分到的哈希内存越碎，冲突概率越高 - 禁用
QUERYTRACEON 8649：这是未公开 trace flag，2019+ 版本可能污染 plan cache，引发不可预知的重编译风暴
避免统计信息过期导致计划误选排序分组
当 SQL Server 低估多列组合的唯一值数量（比如 GROUP BY region, product_category, sales_month），它可能放弃哈希匹配，转而选择 Sort + Stream Aggregate。看起来没报错，实则 tempdb 磁盘排序撑爆，延迟飙升。
- 对参与多列 GROUP BY 的大表，运行
UPDATE STATISTICS dbo.YourTable WITH FULLSCAN, NORECOMPUTE；别依赖自动更新 - WHERE 条件含变量时，加
OPTION (RECOMPILE)让每次执行都重估行数，避免参数嗅探导致的基数误判 - 如果数据天然有序（如按
sales_date分区的大表），可显式加ORDER BY region, product_category, sales_month，引导优化器走流式聚合，绕过哈希/排序两难
索引能帮的其实很有限，但覆盖索引值得试
多列 GROUP BY 本身不直接受索引加速，但若能命中覆盖索引，就能跳过表访问，减少整体内存压力——尤其当聚合列和分组列都在索引中时。
- 建索引优先考虑：分组列顺序按
GROUP BY中的顺序排列，后跟聚合列（如SUM(sales_amount)），例如CREATE INDEX ix_group_cover ON sales(region, product_category, sales_month) INCLUDE (sales_amount) - 注意字符串列长度：若
product_category是varchar(200)，索引键太宽会降低 B-tree 效率，反而拖慢扫描；可考虑用计算列或哈希值替代 - 别为多列 GROUP BY 盲目建索引：没有 WHERE 过滤时，索引扫描仍要读全索引页，内存开销未必比表扫描小
真正卡住的点，往往藏在 GrantedMemory_KB 和 UsedMemory_KB 的差值里，而不是执行计划图标的颜色深浅里。多列组合让估算更脆弱，也更容易触发磁盘回退——盯紧这两个 KB 值，比调一百次索引更管用。
