直接执行SHOW ENGINE INNODB STATUS\G，定位LATEST DETECTED DEADLOCK区块，检查三处：tables in use数量＞1、HOLDS/WAITING表名不一致且含NEW.语句、AFTER触发器在持锁未提交时执行DML——满足任一即大概率是触发器卡住。
怎么看死锁日志里是不是触发器在卡住
直接执行 SHOW ENGINE INNODB STATUS\G，跳到 LATEST DETECTED DEADLOCK 区块，别扫报错 SQL，盯三处：
-
mysql tables in use 2, locked 2—— 数字大于 1 就说明至少涉及两张表，主业务 SQL 通常只动一张表，多出来的那张大概率是触发器带进来的（比如t_log、t_audit） -
HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED中的表名不一致：主事务锁t_order，却在等t_user_points上的锁，立刻去查t_order表上有没有AFTER INSERT触发器 - 堆栈里出现
UPDATE t_log SET status = 'done' WHERE order_id = NEW.id这类含NEW.的语句，基本可断定出自触发器；INSERT INTO t_order后紧跟着UPDATE，就是典型触发器执行痕迹
为什么 AFTER 触发器更容易拖慢整个事务
AFTER INSERT 执行时，新行已落盘并持有行级 X 锁，事务还没提交。此时再执行任何 DML，等于在已有锁基础上叠加新锁请求——锁持有时间被隐式拉长，且无法提前释放。
-
BEFORE INSERT只能改NEW字段值，不产生额外 DML，也就不会引入新锁（除非你主动写SELECT ... FOR UPDATE） -
AFTER INSERT中执行UPDATE stats SET count = count + 1 WHERE type = 'order'，若type无索引，InnoDB 会全表扫描 + 加 Next-Key Lock，瞬间锁住整张统计表 - MySQL 8.0+ 才能在
INNODB STATUS中准确定位多级嵌套触发器里的内层语句；低版本里看到的“阻塞 SQL”往往只是最外层，真正卡点藏在触发器里
触发器里哪些操作会立刻引发锁等待超时
以下行为在并发稍高时，几乎必然导致锁等待超时甚至死锁：
- 跨业务主表的
UPDATE，例如从orders触发器里去改users表余额——一律移出触发器，改用应用层统一锁序（如先锁user，再锁order） -
WHERE条件未命中主键或唯一索引的 DML，比如UPDATE config SET value = 'on' WHERE module = 'payment'，若module无索引，就是全表 X 锁 - 带范围条件的
SELECT ... FOR UPDATE，如SELECT * FROM logs WHERE created_at > DATE_SUB(NOW(), INTERVAL 1 DAY) FOR UPDATE，在 RR 隔离下会锁住整个时间区间 - 调用存储过程，除非该过程明确声明只读、无任何 DML，否则锁路径不可控
怎么快速确认触发器是否卷入当前锁等待
锁等待不一定有死锁日志，但可以交叉验证：
- 查
information_schema.INNODB_TRX中状态为LOCK WAIT的事务，记下trx_mysql_thread_id - 关联
information_schema.INNODB_LOCK_WAITS，拿到blocking_trx_id - 再查
information_schema.PROCESSLIST，用blocking_trx_id对应的线程 ID 查原始语句：SELECT INFO FROM information_schema.PROCESSLIST WHERE ID = ?；如果看到的是INSERT INTO t_order，但该会话却持有t_user表的排它锁，就得立刻检查触发器逻辑 - 查
sys.dm_exec_trigger_stats（SQL Server）或 MySQL 的performance_schema.events_statements_history，看触发器执行耗时是否突增（如从 0.5ms 跳到 300ms），若与锁等待高发时段重合，说明触发器内部可能卡在未索引查询或 I/O 等待上
真正棘手的是：触发器让锁路径变得不可见——你很难从应用日志里看出某次 INSERT 背后悄悄锁了三张表。排查时别只盯错误码，得进死锁图 XML 的 executionStack 找触发器名；优化时也别只删触发器，要控制它的锁粒度和路径。
