触发器让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 这种对锁敏感、对并行更激进的版本里。