触发器不开启独立事务，但会将锁操作纳入主事务，需通过死锁图executionStack中触发器名称、多条DML紧耦合顺序及锁表交叉验证来确认其参与；sys.dm_tran_locks等视图仅显示锁关系，无法直接标识触发器。
触发器本身不开启新事务，但会把锁操作塞进主事务里——这意味着你查不到独立的“触发器事务”，只能从阻塞链和锁持有关系中反推它是否参与了死锁。
怎么看触发器是否在死锁现场
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> 节点可能包含触发器调用栈。关键线索有：
- 堆栈中出现类似
trigger_name、trg_after_insert_order的函数名（不是所有版本都显示全名，有些只显示proc [master]...sp_executesql） - 同一
process id下连续出现多条 DML：先是INSERT INTO t_order，紧接着UPDATE t_log SET status = 'done'—— 这种紧耦合顺序就是触发器执行特征 -
<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。
