JOIN撑爆TempDB主因是执行计划退化为Sort Merge或哈希溢出，诱因包括JOIN字段无索引、数据倾斜、统计信息过期及含ORDER BY/GROUP BY等排序操作；可通过SET STATISTICS XML查实际执行计划中的Spill To TempDb、Hash Match偏差或Sort算子定位。
为什么JOIN会突然把TempDB撑爆
SQL Server在执行JOIN时，如果无法走内存哈希匹配或嵌套循环，就会退化成排序合并（Sort Merge）或强制物化中间结果——这些操作全依赖TempDB。典型诱因是：JOIN字段没索引、数据倾斜严重、统计信息过期，或者查询里混用了ORDER BY、GROUP BY、TOP等触发排序的子句。
现象上，你会看到sys.dm_db_task_space_usage里internal_objects_alloc_page_count飙升，同时Windows事件日志出现TempDB log file is full或Could not allocate space for object in database 'tempdb'错误。
用SET STATISTICS XML快速定位问题算子
在SSMS中打开实际执行计划前，先运行：
SET STATISTICS XML ON;再执行你的JOIN语句。重点看执行计划里是否出现以下节点：
-
Hash Match：如果Build Input行数远大于Probe Input，且EstimateRows和ActualRows偏差超5倍，说明哈希表过大，容易溢出到TempDB -
Sort：任何带Sort的算子都意味着内存不足时会写入TempDB；注意看Memory Grant是否标红（不足） -
Spill To TempDb字样直接出现在算子属性里——这是最明确的信号
别只信“Estimated Plan”，必须看Actual Execution Plan，因为估算可能完全偏离真实数据分布。
JOIN字段缺失索引是最常见硬伤
检查ON条件中的字段是否在各自表上有有效索引，尤其注意复合索引顺序是否匹配JOIN顺序。比如：
SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id AND o.status = 'shipped'那么
orders表上理想索引是(customer_id, status)，而不是(status, customer_id)。
用这个查询快速扫一遍缺失索引建议：
SELECT * FROM sys.dm_db_missing_index_details WHERE database_id = DB_ID()但注意：SQL Server的缺失索引建议不考虑数据倾斜，它推荐的索引在10万行时高效，到1000万行可能反而加重TempDB压力。
更稳妥的做法是结合sys.dm_exec_query_stats查出高逻辑读+高TempDB分配的JOIN语句，再针对性建索引。
统计信息陈旧会让优化器彻底误判
当表数据量变化超20%（或绝对值超500行），而统计信息没更新，优化器就可能选错JOIN算法——比如该走Nested Loop却强行Hash，导致内存预估严重不足，大量Spill。
立即更新统计信息：
UPDATE STATISTICS [schema].[table] WITH FULLSCAN, NORECOMPUTE;但别盲目加
FULLSCAN，大表会锁表且耗时；优先试SAMPLE 30 PERCENT，观察执行计划是否改善。
临时缓解可用OPTION (RECOMPILE)让每次执行都重编译，但这是权宜之计——长期要靠自动更新策略或计划指南固化正确计划。
真正棘手的是分区表或列存储表上的JOIN：统计信息默认只采样一级分区，容易漏掉热点分区的数据倾斜，这时候得手动对热点分区单独更新统计信息。
