如何检测SQL触发器引起的死锁问题_通过动态管理视图定位阻塞源-SQL-PHP中文网

触发器不开启独立事务，但会将锁操作纳入主事务，需通过死锁图executionstack中触发器名称、多条dml紧耦合顺序及锁表交叉验证来确认其参与；sys.dm_tran_locks等视图仅显示锁关系，无法直接标识触发器。

如何检测sql触发器引起的死锁问题_通过动态管理视图定位阻塞源

触发器本身不开启新事务，但会把锁操作塞进主事务里——这意味着你查不到独立的“触发器事务”，只能从阻塞链和锁持有关系中反推它是否参与了死锁。

怎么看触发器是否在死锁现场

SQL Server 的 sys.dm_tran_locks 和 sys.dm_exec_requests 能暴露真实阻塞路径，但不会直接标出“这是触发器干的”。你需要交叉验证三处信息：

在 sys.dm_tran_locks 中找到持有锁（request_status = 'GRANT'）和等待锁（request_status = 'WAIT'）的会话，比对它们锁的表：如果一张表只被主 SQL 访问，另一张表（比如 t_audit 或 t_log）只出现在触发器定义里，且同时出现在两个会话的锁列表中，大概率是触发器带进来的
用 sys.dm_exec_requests 查 blocking_session_id 非 0 的请求，再通过 sql_handle 反查原始语句：SELECT text FROM sys.dm_exec_sql_text(sql_handle) —— 如果看到的是 INSERT INTO t_order，但对应会话又持有了 t_user 表的排它锁，就得立刻去查 t_order 上有没有 AFTER INSERT 触发器更新 t_user
检查 sys.dm_exec_trigger_stats 里的 execution_count 和 total_elapsed_time：单次执行耗时突增（比如从 1ms 跳到 500ms），且恰好与死锁高发时段重合，说明触发器内部可能卡在 I/O、锁等待或未索引查询上

为什么 sys.dm_os_waiting_tasks 不够用

这个视图只告诉你“谁在等什么资源”，但不告诉你“等的资源是谁加的”。比如你看到一个会话在等 LCK_M_U（更新锁），对象是 t_log，但无法确认这把锁来自应用层 UPDATE 还是触发器隐式执行。更麻烦的是，触发器内语句没有独立 session_id，它的锁会合并到父会话的 session_id 下，导致你误判为“单条 SQL 持锁过久”。

真正有用的是组合查询：

SELECT r.session_id, r.status, r.command, r.wait_type, r.wait_time,
       l.resource_type, l.resource_description, l.request_mode,
       t.name AS trigger_name
FROM sys.dm_exec_requests r
JOIN sys.dm_tran_locks l ON r.session_id = l.request_session_id
LEFT JOIN sys.triggers t ON OBJECT_NAME(l.resource_associated_entity_id) = t.parent_class_desc
WHERE r.blocking_session_id  0;

注意：t.parent_class_desc 并非总能匹配成功，重点还是靠 resource_description 里的对象名 + 人工核对触发器定义。

DBCC TRACEON(1222, -1) 日志里怎么认触发器痕迹

启用后，死锁图（deadlock graph）会写入错误日志，其中 <executionstack></executionstack> 节点可能包含触发器调用栈。关键线索有：

堆栈中出现类似 trigger_name、trg_after_insert_order 的函数名（不是所有版本都显示全名，有些只显示 proc [master]...sp_executesql）
同一 process id 下连续出现多条 DML：先是 INSERT INTO t_order，紧接着 UPDATE t_log SET status = 'done' —— 这种紧耦合顺序就是触发器执行特征
<inputbuf></inputbuf> 里只有主 SQL，但 <frame> 的 procname 属性值为 adhoc 或空，而 line 却指向触发器所在数据库，说明执行流已进入触发器上下文

MySQL 用户别套用这套逻辑

MySQL 没有 sys.dm_exec_requests 这类视图，SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 区块根本不会展开触发器内语句。你只能靠间接证据：死锁日志里两个事务都涉及 t_order 和 t_log，而 SHOW CREATE TRIGGER 明确写了 AFTER INSERT ON t_order FOR EACH ROW UPDATE t_log... —— 这时候就该信它了。不要浪费时间在“找触发器 session”上，MySQL 触发器压根没 session 概念。

最易被忽略的一点：触发器内任何未走索引的 WHERE 条件（比如 WHERE user_name LIKE '%abc%'），都会让锁范围从单行升级为间隙锁甚至全表锁，而这个行为在动态视图里只体现为“锁了更多行”，不会提示“因为没索引”。必须手动对触发器每条语句跑 EXPLAIN。