触发器让INSERT变慢是因为其同步串行执行机制：即使空触发器也会强制事务串行化，审计类触发器更将主表写入与日志表写入耦合，导致吞吐腰斩、锁升级频发；高并发下易出现LCK_M_X等等待，需用sys.triggers和dm_exec_trigger_stats定位，临时禁用或重构为异步消费（如audit_queue表+轮询）是有效解法。
触发器为什么让INSERT变慢到不可接受
哪怕只有一行 SELECT 1 的空触发器，也会强制事务串行化——SQL Server 必须等前一个 INSERT 触发逻辑执行完，才能开始下一个。更常见的是审计类触发器，它把“写主表 + 写日志表”变成同步两段操作，吞吐量直接腰斩。高并发下还容易触发锁升级，sys.dm_exec_requests 里常看到 wait_type = LCK_M_X 或 LCK_M_SCH_M。
怎么快速判断触发器是不是瓶颈
别猜，用这几条语句直接查：
SELECT * FROM sys.triggers WHERE parent_id = OBJECT_ID('your_table');-
SELECT * FROM sys.dm_exec_trigger_stats WHERE object_id = OBJECT_ID('your_trigger');（看execution_count和total_elapsed_time） - 在 Profiler 或 Extended Events 中捕获
sp_statement_completed，过滤object_name = 'your_trigger'，看单次耗时是否稳定超过 5ms
临时禁用 vs 彻底重构：两种路径怎么选
如果业务允许短时间延迟（比如审计日志晚几秒入库），优先走临时禁用路径，风险低、见效快：
- 加一个会话级开关变量，在触发器开头加
IF @disable_audit_trigger = 1 RETURN; - 导入前执行
SET @disable_audit_trigger = 1;，导入完再设为 0 - 注意：不能用
DISABLE TRIGGER，因为会阻塞 DDL，且无法按会话粒度控制
如果必须实时、强一致，就重构为异步消费：
- 触发器只做一件事：把变更数据写进一张轻量
audit_queue表（无索引、无外键、WITH (TABLOCK)批量写） - 另起一个 SQL Agent Job 或外部服务轮询该表，批量消费后清空
- 关键点：消费端必须处理幂等，避免主从延迟导致重复写入
重构时最容易被忽略的锁和事务陷阱
触发器默认运行在主 INSERT 的同一事务中，这意味着：
- 触发器里的
INSERT INTO audit_log会延长主事务持有锁的时间，增加阻塞概率 - 如果 audit_log 表上有非聚集索引或触发器自身又调用了 UDF，性能会指数级恶化
- 千万别在触发器里调用
OPENROWSET、EXEC xp_cmdshell或远程查询——它们会拖垮整个事务上下文
真正省事的做法是：删掉触发器，把审计逻辑提到应用层，用带事务的双写（或本地消息表 + 发布订阅）替代。SQL Server 的触发器不是万能胶，而是性能定时炸弹——尤其在 SQL Server 2022 这种对锁敏感、对并行更激进的版本里。
