SQL触发器本身不直接引起超时，但会将毫秒级操作拖慢至数十秒，导致应用端超时；根本原因是其将慢逻辑嵌入事务主路径，且执行耗时隐藏在原始语句中，需通过Profiler Duration异常、attention事件及系统视图查询确认。
SQL触发器本身不会直接“引起”超时错误，但它会让原本毫秒级的 INSERT 或 UPDATE 变成几十秒的阻塞操作——应用端等不到结果，自然抛出 Timeout expired。真正的问题是：触发器把慢逻辑塞进了事务主路径，而你根本没意识到它在跑。
为什么用 SQL Server Profiler 能抓到触发器导致的超时
Profiler（或更现代的扩展事件）能捕获每个语句的真实执行耗时、是否被阻塞、是否引发锁等待——而触发器的执行不会单独显示为“TRIGGER”，它会合并进原始语句的 sql_batch_completed 事件里，但持续时间会异常拉长。关键线索有三个：
-
Duration字段远超同类语句（比如普通插入通常 5ms，这里显示 28400ms） - 对应
session_id紧接着出现attention事件（表示客户端主动取消） -
TextData显示的是你的原始INSERT INTO orders...，但耗时爆炸——这时就要怀疑：这张表有没有触发器？
如何确认触发器是罪魁祸首（不依赖 Profiler）
别急着翻代码，先查数据库元数据。SQL Server 中触发器和表强绑定，直接查系统视图比翻源码快得多：
- 运行
SELECT * FROM sys.triggers WHERE parent_id = OBJECT_ID('orders')，看是否存在ON orders AFTER INSERT类型触发器 - 对查到的触发器，用
SELECT definition FROM sys.sql_modules WHERE object_id = XXX拿出实际逻辑，重点扫视：WAITFOR、OPENQUERY、EXEC外部存储过程、多层JOIN更新、循环游标（DECLARE cursor） - 临时禁用（非删除！）验证：
DISABLE TRIGGER tr_orders_after_insert ON orders，再跑一次原操作，如果超时消失，基本锁定问题
触发器内哪些写法最易拖垮事务并引发超时
不是所有触发器都危险，但以下模式几乎必然导致应用超时，尤其在线上批量导入或高并发场景：
- 调用含网络 I/O 的存储过程，例如
EXEC send_notification_proc @order_id—— 这会让整个事务卡住，直到邮件服务器响应或超时 - 在触发器里做跨库查询，如
SELECT @count = COUNT(*) FROM other_db.dbo.log_table WHERE order_id = i.id—— 链接服务器开销巨大，且可能触发分布式事务 - 用标量子查询逐行计算，例如
UPDATE t SET total = (SELECT SUM(amount) FROM order_items WHERE order_id = t.id)—— 表越大，每行越慢，批量插入 N 行就执行 N 次全表扫描 - 未加
WHERE条件的整表更新，例如在员工表触发器中写UPDATE dept_stats SET emp_count = (SELECT COUNT(*) FROM employees)—— 锁住整张统计表，阻塞其他请求
Profile 抓到长耗时后，怎么改才不破业务
不能只停用触发器了事。核心原则是：把“必须立刻完成”的事留下，把“可以稍后做”的事踢出去。具体落点很实在：
- 把发通知、写审计日志、同步外部系统这类操作，改成往一张轻量
notification_queue表里INSERT一条记录，再由后台作业（SQL Agent Job / 应用定时任务）消费——触发器执行时间从秒级降到毫秒级 - 把复杂统计逻辑（如部门总薪资）从触发器移出，改为定期刷新（每 5 分钟跑一次
UPDATE dept_stats FROM (SELECT dept_id, SUM(salary) s FROM employees GROUP BY dept_id)），配合last_modified时间戳只刷增量 - 如果必须校验（如库存不能为负），用
CHECK CONSTRAINT或INSTEAD OF触发器 + 集合式判断（NOT EXISTS (SELECT 1 FROM inserted i LEFT JOIN inventory inv ON i.item_id = inv.item_id WHERE inv.qty + i.qty < 0)），避免逐行IF
最容易被忽略的一点：触发器修改的数据，可能又触发下一轮触发器（A→B→A），形成隐式递归。哪怕每次只多花 20ms，嵌套 5 层就是 100ms —— 在 Profiler 里看不到“递归”字样，只看到单条语句耗时越来越高。上线前务必用真实批量数据压测，而不是单行测试。
