SQL Server大数据量GROUP BY卡住主因是查询内存授予不足，应查执行计划中GrantedMemory_KB与UsedMemory_KB是否接近或超限，并配合调优MIN_GRANT_PERCENT、MAXDOP及tempdb多文件预分配。
SQL Server 的 GROUP BY 在大数据量下卡住，十有八九不是逻辑写错了，而是内存没分够——它默认用 work_mem（PostgreSQL）或 max server memory 下的内部缓冲区做哈希分组，但 SQL Server 实际靠的是 query memory grant 和 max degree of parallelism 联动分配。不调这俩，索引再好也救不了临时哈希表溢出到磁盘。
查清当前查询到底用了多少内存
别猜，直接看执行计划里的 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看全局——它反映的是实例级缓存，和单个GROUP BY的查询内存 grant 无关
手动控制内存分配：OPTION (QUERYTRACEON 8649) 不可靠，改用 MAXDOP + MIN_GRANT_PERCENT
SQL Server 2016+ 支持在查询末尾加 OPTION (MIN_GRANT_PERCENT = 30, MAXDOP 2)，强制给这个 GROUP BY 至少分到估算内存的 30%。比盲目开 MAXDOP 0 更稳——后者容易让小查询抢光内存，反而把大查询饿死。
-
MIN_GRANT_PERCENT是硬保底，不是建议值；设太高（如 80）可能导致并发查询排队 -
MAXDOP必须配合设：并行度越高，每个线程分到的内存越碎，哈希效率反而下降；对单表GROUP BY，MAXDOP 2或4往往比0更快 - 禁用
QUERYTRACEON 8649：这是未公开的调试标记，2019+ 版本可能触发不可预知的 plan cache 污染
避免哈希分组退化成排序分组
当 SQL Server 估算行数严重偏低（比如统计信息过期），它可能选错执行计划：该走哈希匹配却走了 Sort + Stream Aggregate，结果 ORDER BY 式排序把 tempdb 塞爆。这时 GROUP BY 看似没报错，实则慢得离谱。
- 更新统计信息：
UPDATE STATISTICS dbo.YourTable WITH FULLSCAN, NORECOMPUTE（仅对关键大表），别依赖自动更新 - 用
OPTION (RECOMPILE)让每次执行都重估参数敏感值，尤其当WHERE条件含变量时 - 如果确定数据天然有序（如按时间分区的大表），可加
ORDER BY提示引导流式聚合：GROUP BY a, b ORDER BY a, b OPTION (RECOMPILE)
真正容易被忽略的点：tempdb 配置比 query memory 更致命
哪怕你把 MIN_GRANT_PERCENT 设到 50%，只要 tempdb 文件只有 1 个、初始大小 8MB、自动增长步长 64MB，所有哈希溢出都会卡在磁盘 I/O 上。SQL Server 的 GROUP BY 内存机制是“先尽力哈希，不够就落盘”，而落盘路径全压在 tempdb。
- 必须为
tempdb配多个等大的数据文件（一般等于 CPU 核数，上限 8 个），且关闭自动增长，预分配足够空间 - 检查
sys.dm_db_task_space_usage，确认session_id对应的user_objects_alloc_page_count是否异常高——那是哈希表反复申请/释放页的信号 - 不要试图靠增大
max server memory解决问题：它只影响 buffer pool，不影响 query memory grant 的计算基准
