触发器本身不直接导致死锁，但因与主事务共享上下文且隐式执行多条DML，若访问表未按统一顺序加锁，极易引发死锁；排查需从死锁图XML中executionStack确认触发器参与，结合锁视图、索引统计与并发模拟验证加锁路径。
怎么看触发器是不是死锁元凶
触发器本身不直接“导致”死锁，但它会在主事务上下文中隐式执行，把原本简单的 UPDATE 变成“主SQL + 触发器内多条DML”的复合事务。一旦触发器内部访问了其他表、又没按统一顺序加锁，就极易卷入死锁环。
排查第一步不是翻触发器代码，而是确认死锁现场是否真有它参与：打开死锁图（xml_deadlock_report），看 process-list 里每个 inputbuf 的 SQL 是否包含 INSERT/UPDATE 主表语句——再顺藤摸瓜查它的 executionStack，里面如果出现 trg_after_update_order 这类名字，基本坐实。
- 别只盯着报错应用日志里的“1205错误”，那只是结果；触发器的执行痕迹藏在死锁图的 XML 深处
-
sys.dm_exec_trigger_stats只统计执行次数，不能反映锁行为；真正要看的是触发器实际执行时的资源等待路径 - 如果触发器里调用了存储过程或函数，
executionStack可能只显示到外层，得结合sys.dm_exec_sql_text手动反查 handle 对应的完整文本
检查触发器内的事务边界是否失控
SQL Server 中触发器**没有独立事务**，它和引发它的语句共用同一个事务。这意味着：主事务还没提交，触发器里的 UPDATE users SET last_modified = GETDATE() 就已经持有了 users 表上的行锁——而另一个并发事务可能正卡在这行上等你释放。
常见失控场景：
- 触发器里执行远程调用（如
sp_OACreate调 HTTP）、大体积日志写入或复杂计算，人为拉长锁持有时间 - 触发器内嵌套调用另一个含 DML 的存储过程，且该过程未显式使用
SET XACT_ABORT ON，异常时事务状态残留 - 误用
@@TRANCOUNT判断做条件分支，比如IF @@TRANCOUNT = 0 BEGIN BEGIN TRAN ...——在触发器里永远不成立，但开发者以为“安全”就放行了
怎么验证触发器锁竞争路径是否一致
死锁本质是加锁顺序冲突。两个事务都操作 orders 和 inventory 表，但 A 先锁 orders 再锁 inventory，B 反过来，就闭环了。触发器会让这个顺序更隐蔽。
实操建议：
- 用
SELECT * FROM sys.dm_tran_locks WHERE resource_database_id = DB_ID()查当前所有锁，重点看request_mode（X还是U）和resource_description（比如KEY: 5:72057594044870656 (8194a02e9e3c)） - 对触发器涉及的每张表，运行
DBCC SHOW_STATISTICS('table_name', 'index_name')确认 WHERE 条件是否走索引；没索引的WHERE status = 'pending'在触发器里一跑，就是全表行锁升级为页锁 - 在测试环境模拟高并发更新主表，用 Extended Events 捕获
sql_batch_completed+lock_acquired事件，导出后按session_id分组，画出各事务真实加锁序列
临时绕过与长期修复怎么做
线上救火时，禁用触发器比改代码快得多，但必须清楚代价：禁用 trg_update_stock_on_order 可能导致库存数据不一致，不能无脑操作。
- 紧急缓解：
DISABLE TRIGGER trg_update_stock_on_order ON orders，但务必同步开启监控，确认下游补偿逻辑（如定时任务）已接管 - 重构方向：把触发器中可异步的操作（如写审计日志、发消息）拆到 Service Broker 或外部队列；只保留强一致性要求的锁内操作
- 最易被忽略的一点：触发器里所有
SELECT都默认带共享锁，哪怕只是SELECT @cnt = COUNT(*) FROM order_items WHERE order_id = @id——加WITH (NOLOCK)要谨慎，但加WITH (READPAST)或改用READ COMMITTED SNAPSHOT隔离级别往往更安全
触发器的锁问题从来不是孤立的，它总和主业务逻辑的事务粒度、索引覆盖、甚至应用层重试策略缠在一起。单点修改容易漏掉耦合路径，得从死锁图里那个小小的 inputbuf 开始，一层层往回捋执行栈和资源请求链。
