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 <spid></spid>，之后再运行DBCC FREESYSTEMCACHE('ALL')清理残留缓存页
收缩TempDB前必须确认的三件事
盲目DBCC SHRINKFILE不仅效果差，还可能引发页面碎片和后续自动增长风暴。真正有效的收缩，必须建立在“空间已实际释放”的前提下。
- 先确认无活跃版本依赖：
SELECT * FROM sys.dm_tran_version_store返回空集才安全 - 确保没有未完成的内部操作：运行
CHECKPOINT强制刷脏页，再等几秒 - 收缩目标值要留余量：设为初始大小（如1024MB）而非0，避免下次立刻触发自动增长
最常被忽略的是——tempdb 文件路径还在系统盘（C:\），而暴涨后即使收缩了，磁盘空间也未必能及时回收给OS。迁移tempdb到独立高速磁盘，比反复收缩更治本。
