SQL Server GROUP BY用tempdb根本原因是Hash Match(Aggregate)内存不足被迫落盘；应建有序索引使输入天然有序以启用Stream Aggregate，或加OPTION(MIN_GRANT_PERCENT=25)保底内存防溢出。
SQL Server GROUP BY为什么总用到tempdb工作表
根本原因不是数据量大，而是执行计划选了Hash Match (Aggregate)且内存不够——它会把哈希桶刷到tempdb，表现为大量WRITELOG等待、tempdb文件暴涨，甚至触发error 1101或error 701。这不是“用了临时表”，是SQL Server被迫把中间哈希结构落盘。
怎么让GROUP BY走Stream Aggregate而不是Hash Match
关键不是调参数，是让输入数据天然有序。SQL Server只有在输入已按分组字段排序时，才会启用轻量级的Stream Aggregate（不占额外内存、不碰tempdb）。
- 建联合索引时，把
WHERE等值条件字段放最左，分组字段紧随其后：比如WHERE status = 'shipped' GROUP BY order_date, customer_id，索引应为(status, order_date, customer_id) - 避免在
GROUP BY字段上用函数：如GROUP BY YEAR(order_date)会破坏索引有序性，改用范围过滤+原字段分组 - 确认执行计划中
Stream Aggregate上游节点的Ordered属性为True；若上游是Index Scan但Ordered=False，说明索引没被用于排序
当必须用Hash Match时，怎么防止它溢出到tempdb
靠MIN_GRANT_PERCENT保底内存，不是靠盲目调大max server memory。SQL Server不会因为你把实例内存设高，就自动给这个查询多分内存。
- 在查询末尾加
OPTION (MIN_GRANT_PERCENT = 25, MAXDOP 2)：25%是估算内存的硬保底，MAXDOP 2避免并行线程碎片化争抢 - 别信
DBCC MEMORYSTATUS——它不反映单个查询的内存授予状态；改用sys.dm_exec_query_memory_grants查granted_memory_kb和required_memory_kb是否接近 - 如果执行计划XML里出现
Warning: Memory Grant Warning，说明已降级，此时加MIN_GRANT_PERCENT比重建索引更立竿见影
哪些写法会悄悄逼SQL Server用Hash Match
即使有完美索引，以下操作也会让优化器放弃Stream Aggregate：
-
HAVING里带聚合计算：如HAVING COUNT(*) > 100，会强制先算完全部分组再过滤，无法流式剪枝 -
SELECT *+GROUP BY：哪怕分组字段有索引，回表读取其他列仍会打断有序流 - 隐式类型转换：比如
GROUP BY user_id，但user_id是VARCHAR而JOIN条件用了INT，导致索引失效 - 统计信息严重过期：优化器误估行数，以为数据无序，直接选
Hash Match——运行UPDATE STATISTICSwithFULLSCAN后再看执行计划
