sql server千万级group by导致tempdb溢出的主因有四：哈希/排序溢出、快照隔离下版本链堆积、隐式物化中间结果、tempdb文件配置不当；需针对性优化内存、索引、隔离级别及文件布局。
GROUP BY 操作触发哈希匹配或排序溢出到 TempDB
SQL Server 对千万级数据做 GROUP BY 时，若无法在内存中完成聚合，就会把中间结果写入 TempDB——典型表现是执行计划里出现 Hash Match (Aggregate) 或 Sort 算子，并带红色警告“Warning: Operator used tempdb”。这不是配置问题，而是资源申请失败后的自然降级。
- 当
GROUP BY字段无索引、或数据分布极不均匀（如大量 NULL 或重复值），优化器倾向选择哈希聚合，但初始内存授予不足时，哈希表会“溢出”（spill）到 TempDB - 若启用并行执行，每个线程都可能独立分配 TempDB 空间，总用量呈倍数增长
-
MAXDOP 1可降低并发溢出风险，但未必减少总量；真正有效的是让优化器有足够内存预估，比如调高服务器的min server memory（需权衡其他组件）
快照隔离下 GROUP BY 与 UPDATE 混用导致版本链堆积
如果查询本身不修改数据，但所在数据库启用了 READ_COMMITTED_SNAPSHOT，而同一时间有长事务在更新被分组的基表，那么 GROUP BY 查询会读取行版本，这些版本必须保留在 TempDB 中直到长事务结束。此时看 sys.dm_tran_active_snapshot_database_transactions，elapsed_time_seconds 超过 300 的会话就是元凶。
- 执行
SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME()确认是否开启快照 - 临时关闭快照需重建连接，且业务逻辑必须确认不依赖该隔离语义，否则可能引发脏读或不可重复读
- 单纯收缩 TempDB 文件无效——只要版本链还活着，空间就无法释放
临时结果集未及时释放：CTE、子查询、窗口函数的隐式物化
写法看似简洁的语句，如嵌套多层 CTE 或使用 ROW_NUMBER() OVER (PARTITION BY ...) 处理千万行，SQL Server 可能将中间结果集物化到 TempDB。尤其当外层查询加了 ORDER BY 或 TOP，优化器无法流式处理时，物化几乎不可避免。
- 用
SET STATISTICS XML ON查执行计划，找RelOp PhysicalOp="Compute Scalar"或Window Spool节点，它们常伴随高EstimateRows和TempDbPages - 避免在顶层直接对大结果集做
ORDER BY；改用覆盖索引+键查找，或拆成两步：先聚合 ID 列，再 JOIN 原表取字段 -
OPTION (RECOMPILE)有时能帮优化器拿到更准的基数估算，减少误判物化的概率
TempDB 文件配置跟不上突发负载
即使查询本身合理，若 TempDB 数据文件只有 1 个、初始大小仅 8MB、自动增长设为 10%，面对千万级 GROUP BY 的瞬时写入压力，文件反复扩展 + 磁盘碎片会拖慢整个过程，表现为日志/数据文件同时暴涨、pagelatch_up 等待飙升。
- 生产环境应为 TempDB 配置多个等大的数据文件（建议 CPU 核数 ≤ 8 时设 4 个，>8 时最多 8 个），例如：
ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev2', FILENAME = 'D:\SQLData\tempdb2.ndf', SIZE = 2048MB, FILEGROWTH = 512MB) - 日志文件保持 1 个即可，但初始大小至少 1024MB，
FILEGROWTH设为固定值（如 512MB），禁用百分比增长 - 所有文件必须放在低延迟、独立于系统盘的 SSD 上；C 盘放 TempDB 是多数线上事故的共同起点
真正难处理的从来不是“怎么收缩”，而是“为什么收缩不了”——当看到 DBCC SHRINKFILE 返回成功却空间纹丝不动，基本可以确定：有活动事务、版本链或内部对象正牢牢锁住那些页。这时候查 sys.dm_db_session_space_usage 和 sys.dm_exec_requests 比重启更管用，但得快，因为长事务可能正在滚雪球。
