SQL Server触发器通过快照隔离、排序/哈希溢出及行版本存储间接引爆tempdb；批量操作将集合操作拆为行级事务，每行均生成版本并放大内部对象开销。
触发器本身不直接写 tempdb，但批量执行时会通过快照隔离、内部排序、行版本存储等机制间接引爆 tempdb 空间——根本原因是它把单次集合操作强行拆成 N 次行级事务，每行都触发完整执行链。
触发器如何激活 tempdb 的版本存储
只要数据库启用了 READ_COMMITTED_SNAPSHOT 或 ALLOW_SNAPSHOT_ISOLATION，任何被触发器修改的行都会在 tempdb 中生成旧版本。批量插入 100 万行 → 触发器对每行执行一次 UPDATE → 产生 100 万条行版本记录。
- 检查是否启用：运行
SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME() - 版本存储不释放的典型信号：
sys.dm_tran_active_snapshot_database_transactions中存在elapsed_time_seconds > 300的长事务 - 触发器内哪怕只更新一个字段（如
UPDATE audit SET processed = 1 WHERE id IN (SELECT id FROM inserted)），也会触发整行版本写入
触发器 SQL 执行计划导致 tempdb 溢出
触发器里写的语句若没走索引、含函数或类型转换，SQL Server 就会在 tempdb 中做排序、哈希匹配或构建工作表——而这些操作在批量场景下会被放大 N 倍。
- 常见陷阱：
WHERE UPPER(name) = 'ABC'、WHERE datepart(year, created_at) = 2025这类非 SARGable 条件 - 验证方式：在触发器中加
SET STATISTICS XML ON，看执行计划里是否有PhysicalOp="Sort"或PhysicalOp="Hash Match" - 表变量（
@t）在触发器中插入大量数据时，虽不建统计，但物理存储仍在 tempdb，且不易被监控发现
禁用触发器后 tempdb 仍不收缩？查这三处
停用触发器只是切断新增压力，已有空间不会自动还给系统——必须确认底层资源是否真正释放。
- 运行
DBCC OPENTRAN：看是否存在未提交事务（哪怕只是BEGIN TRAN后忘了COMMIT） - 查
sys.dm_db_file_space_usage：重点关注version_store_reserved_page_count是否下降，而非只看总空间 - 检查会话级 tempdb 分配：
sys.dm_db_session_space_usage中internal_object_alloc_page_count高的 session，可能是触发器执行残留
真正难处理的不是“触发器占了 tempdb”，而是它让版本存储、内部对象、用户临时表三者同时膨胀，且彼此掩盖根因。排查时别只盯着 tempdb 文件大小，先锁定是哪一类空间（用户对象 / 内部对象 / 版本存储）在涨，再反推对应触发器行为。
