触发器执行慢的主因是tempdb版本存储瓶颈、远程查询同步等待、嵌套超限、inserted/deleted表缺失索引；需检查tempdb配置、禁用read_committed_snapshot验证、移除远程操作、限制嵌套深度、为临时表建索引。
触发器执行慢，先看是否在 tempdb 里卡住
SQL Server 2022 中 DML 触发器（尤其是 AFTER 类型）默认启用行版本控制，所有触发器逻辑涉及的行版本都会写入 tempdb。如果 tempdb 文件配置不合理（比如单个数据文件、未预分配空间、放在慢盘上），就会成为明显瓶颈。现象包括：触发器执行时间波动大、sys.dm_os_waiting_tasks 中大量出现 PAGELATCH_UP 或 WRITELOG 等待，且集中在 tempdb 的 version store 相关页。
实操建议：
- 检查
tempdb文件数：应等于逻辑 CPU 核心数（上限通常为 8），且每个文件大小一致、启用了自动增长但初始大小 ≥ 1 GB - 运行
SELECT * FROM sys.dm_db_file_space_usage查看version_store_reserved_page_count是否持续高位 - 临时禁用触发器所在数据库的
READ_COMMITTED_SNAPSHOT（仅用于验证）：ALTER DATABASE [YourDB] SET READ_COMMITTED_SNAPSHOT OFF—— 如果性能明显回升，说明版本存储是主因
触发器里调了远程查询或链接服务器？立刻砍掉
触发器中使用 OPENQUERY、四部分命名（如 [RemoteSrv].[DB].[Schema].[Table]）或 EXEC AT 调用远程对象，会强制触发器事务跨网络同步等待，极易导致锁升级、阻塞链延长，且错误不易捕获（比如远程超时可能只报 Timeout expired 而非具体位置）。
实操建议：
- 用
SELECT OBJECT_DEFINITION(OBJECT_ID('YourTriggerName'))提取触发器定义，全文搜索OPENQUERY、EXEC AT、方括号包围的服务器名 - 把远程操作移出触发器，改由应用层异步处理，或改用 Service Broker + 消息队列解耦
- 若必须保留在数据库内，至少改用异步代理作业（
sp_start_job）触发，避免阻塞主事务
触发器嵌套深度超 32 层？查 @@NESTLEVEL 和递归开关
SQL Server 对触发器嵌套有硬限制：最大 32 层。一旦触发器内部修改了自身所在的表（比如 UPDATE 表 A 的触发器又去 UPDATE 表 A），就可能触发隐式递归。当 @@NESTLEVEL 达到 32，语句直接失败并报错 Msg 217, Level 16, State 1, Procedure xxx, Line y: Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32)。
实操建议：
- 在触发器开头加
IF @@NESTLEVEL > 5 RETURN快速退出深层嵌套（数值按实际业务调整） - 检查数据库级设置：
SELECT DATABASEPROPERTYEX('YourDB', 'IsRecursiveTriggersEnabled')—— 若为 1，且业务不需要递归，建议关掉：ALTER DATABASE [YourDB] SET RECURSIVE_TRIGGERS OFF - 用
sys.dm_exec_trigger_stats查看各触发器的execution_count和total_elapsed_time，识别高频+高耗时组合
触发器没走索引？重点盯 INSERTED/DELETED 表连接
触发器里对 INSERTED 或 DELETED 临时表做 JOIN 或 WHERE 过滤时，SQL Server 不会自动为其建索引。如果连接条件没覆盖好、或用了函数包装字段（如 UPPER(Inserted.Name)），会导致嵌套循环 + 表扫描，尤其在大批量操作（如批量导入）时性能断崖下跌。
实操建议：
- 把关键关联字段显式转换为带索引的物理表结构：例如，先
SELECT ... INTO #tmp FROM INSERTED，再对#tmp建唯一索引（CREATE UNIQUE CLUSTERED INDEX IX_tmp_id ON #tmp(id)） - 避免在
INSERTED/DELETED上用LIKE '%xxx%'、CONVERT()、ISNULL()等破坏 SARG 性能的操作 - 用
SET STATISTICS XML ON捕获执行计划，确认是否出现Table Scan或Index Scan扫描INSERTED/DELETED—— 这是典型信号
触发器性能问题最难缠的地方不在语法本身，而在它“看不见的上下文”：事务范围、锁粒度、版本存储开销、以及和外部系统的耦合深度。哪怕一行代码改得再干净，只要它被绑在主业务事务里，就天然承担着整个链路的稳定性代价。
