确认Hash Match溢出需查sys.dm_db_session_space_usage中internal_objects_alloc_page_count>100000的会话，再结合执行计划SpillLevel>0或XML中SpillToTempDb="1"判断；根本原因是统计信息过期、过滤未下推或连接列无索引，临时表缺索引亦是隐蔽诱因。

临时表 JOIN 大表本身不爆 tempdb，真正爆的是 Hash Match 或 Sort 操作因内存估算失败而溢出到磁盘——这几乎总是统计信息过期、过滤未下推、或连接列无有效索引导致的。

怎么确认是 Hash Match 在 spill（溢出）？

别看错误日志，直接查运行时分配：

• 执行 SELECT session_id, internal_objects_alloc_page_count FROM sys.dm_db_session_space_usage WHERE internal_objects_alloc_page_count > 100000，找出高占用会话
• 用该 session_id 关联 sys.dm_exec_requests 和 sys.dm_exec_sql_text，拿到正在跑的 SQL
• 在图形化执行计划里找 Hash Match 算子，右键 → 属性 → 看 SpillLevel 是否 > 0；或在 XML 计划里搜 <relop. match></relop.>

为什么加了索引，JOIN 还走 Hash Match？

索引对 Hash Match 没有“禁用”效果；优化器选它，是因为它觉得这是最快路径——而这判断严重依赖两件事：

• DBCC SHOW_STATISTICS 显示连接列的 Rows 和 Rows Sampled 差距大 → 统计信息过期，必须 UPDATE STATISTICS
• 执行计划里 GrantedMemoryKB 远小于实际需要（比如估算 1 万行 × 行宽 200 字节 ≈ 2MB，但只批了 512KB）→ 内存不足强制 spill
• WHERE 条件写在外层（如 FROM #tmp t JOIN orders o ON t.id = o.user_id WHERE o.order_date >= '2025-01-01'），优化器看不到过滤后的真实基数，误判驱动表大小

临时表本身没索引，是最隐蔽的坑

你建了 #tmp，INSERT 了几百万行，然后 JOIN 大表——但 #tmp 默认无任何索引，优化器只能扫全表，还大概率选 Hash Match。这不是语法错，是设计盲区：

• 显式给临时表加索引：CREATE INDEX IX_#tmp_user_id ON #tmp(user_id)（注意：SQL Server 2014+ 支持在临时表上建非聚集索引）
• 更稳妥的做法：把过滤和 JOIN 拆开，先 INSERT INTO #tmp_filtered SELECT * FROM #tmp WHERE ...，再 JOIN，让优化器分阶段估算
• 避免用表变量 @t 替代 #tmp 做大结果集操作——表变量无统计信息，优化器一律按 1 行估算，极易触发灾难性 Hash Match

紧急干预和长期规避的关键差异

临时表 JOIN 爆 tempdb 的难处在于：它往往不报错，只变慢；或者只在高峰期偶发 spill，监控阈值很难设准。最易被忽略的是——

• spill 发生后，internal_objects_alloc_page_count 不会在查询结束后立刻归零，而是等到会话断开才释放；这意味着一个长连接的旧查询可能持续占着几十 GB tempdb 空间，新查询全被卡住
• 用 OPTION (RECOMPILE) 能绕过参数嗅探引发的低效计划，但它治标不治本；如果底层统计信息常年不更新，下次参数一换，又退化
• tempdb 文件数量配得再多，只要大小不一致（比如一个 8GB、一个 16GB），比例填充就失效，所有 Hash Match spill 都往小文件里挤，I/O 争用比空间不足更早拖垮系统