TempDB暴涨主因是快照隔离下大范围UPDATE产生海量行版本、未走索引导致排序/哈希溢出，或长事务未提交致空间无法释放；需查活动快照事务、执行计划警告及未提交事务，并在确认空间已释放后谨慎收缩。

UPDATE语句触发大量版本存储，TempDB暴涨

SQL Server在启用快照隔离（READ_COMMITTED_SNAPSHOT 或 ALLOW_SNAPSHOT_ISOLATION）时，每个被修改的行都会在tempdb中保留旧版本。一次大范围UPDATE（比如没加WHERE、或WHERE未走索引）可能产生数百万行版本记录，直接撑爆tempdb数据文件。

这不是“临时表用多了”，而是行版本链（row version chain）持续累积——只要事务未提交、或有长运行查询正在读取快照，这些版本就无法被清理。

• sys.dm_tran_active_snapshot_database_transactions 可查仍在占用版本存储的会话，重点关注 elapsed_time_seconds 大于 300 的
• 检查是否误开了快照：运行 SELECT is_read_committed_snapshot_on, snapshot_isolation_state FROM sys.databases WHERE name = 'your_db'
• 若业务不依赖快照语义，建议关闭 READ_COMMITTED_SNAPSHOT（需重启连接生效）

UPDATE未走索引导致排序/哈希溢出到TempDB

当UPDATE涉及非SARGable条件（如 WHERE UPPER(name) = 'ABC'）、或更新列上有未覆盖的索引维护需求（如含计算列、XML索引），SQL Server可能被迫在tempdb中执行排序（Sort）、哈希匹配（Hash Match）或构建中间工作表——尤其在并行执行计划下，每个线程都可能分配独立的tempdb页。

典型现象是执行计划里出现红色警告图标 + “Warning: Operator used tempdb”提示，且sys.dm_exec_query_stats中该语句的total_pages_used异常高。

• 用 SET STATISTICS XML ON 捕获实际执行计划，重点看 RelOp 节点是否有 PhysicalOp="Sort" 或 PhysicalOp="Hash Match"
• 检查UPDATE语句的WHERE和SET子句是否能命中索引；避免在过滤字段上用函数、类型转换
• 对大表批量更新，拆成小批次（例如 TOP (5000) WHERE ... 循环），减少单次内存授予压力

大事务未提交，TempDB空间无法释放

哪怕只是BEGIN TRAN; UPDATE ...; 后忘了 COMMIT 或 ROLLBACK，整个事务生命周期内所有修改的行版本、内部对象（如排序缓冲区、游标工作表）都会锁住在tempdb中。此时DBCC SHRINKFILE 基本无效，因为空间被活动事务“持有”。

常见诱因包括：SSIS包卡住、应用层连接池未正确释放、存储过程中异常跳过COMMIT路径。

• 查阻塞源头：SELECT session_id, blocking_session_id, wait_type, last_wait_type FROM sys.dm_exec_requests WHERE blocking_session_id 0
• 定位长事务：DBCC OPENTRAN('your_db') 直接显示最早未提交事务的SPID和开始时间
• 强制终止（谨慎！）：KILL ，之后再运行 DBCC FREESYSTEMCACHE('ALL') 清理残留缓存页

收缩TempDB前必须确认的三件事

盲目DBCC SHRINKFILE不仅效果差，还可能引发页面碎片和后续自动增长风暴。真正有效的收缩，必须建立在“空间已实际释放”的前提下。

• 先确认无活跃版本依赖：SELECT * FROM sys.dm_tran_version_store 返回空集才安全
• 确保没有未完成的内部操作：运行 CHECKPOINT 强制刷脏页，再等几秒
• 收缩目标值要留余量：设为初始大小（如1024MB）而非0，避免下次立刻触发自动增长

最常被忽略的是——tempdb 文件路径还在系统盘（C:\），而暴涨后即使收缩了，磁盘空间也未必能及时回收给OS。迁移tempdb到独立高速磁盘，比反复收缩更治本。