如何分析SQL触发器造成的锁等待-SQL-PHP中文网

直接执行show engine innodb status\g，定位latest detected deadlock区块，检查三处：tables in use数量＞1、holds/waiting表名不一致且含new.语句、after触发器在持锁未提交时执行dml——满足任一即大概率是触发器卡住。

如何分析sql触发器造成的锁等待

直接执行 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 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 等待上