死锁日志中触发器作祟的判断依据是：在show engine innodb status\g的latest detected deadlock区块中，若两事务持锁与等待锁跨表且顺序相反（如a持orders锁等user_points、b持user_points锁等orders），并存在含new./old.的非主业务表dml（如update order_log where order_id = new.id），即可确认触发器引发死锁。
怎么看死锁日志里是不是触发器在作祟
别只盯着应用报错的那条 SQL，真正关键的是 SHOW ENGINE INNODB STATUS\G 输出中 LATEST DETECTED DEADLOCK 区块里的两个事务细节。
- 检查
waiting for this lock和holds the locks是否跨了不同表，且顺序相反——比如事务 A 持有orders锁、等待user_points；事务 B 持有user_points、等待orders，这是典型的触发器引发的反向加锁链 - 找有没有带
NEW.或OLD.的语句，例如UPDATE order_log SET status = 'processed' WHERE order_id = NEW.id，基本可断定出自AFTER INSERT触发器 - 若某个事务在非主业务表（如积分表、日志表）上执行了
UPDATE或SELECT FOR UPDATE，而该操作不在主业务逻辑里显式发起，大概率是触发器越界执行
AFTER 和 BEFORE 触发器哪个更容易锁住整个事务
AFTER INSERT 是高危区，BEFORE INSERT 相对安全——不是因为语法更“轻”，而是锁行为本质不同。
-
AFTER INSERT执行时，新行已落盘并持有行级 X 锁，事务尚未提交；此时再执行其他 DML（比如更新统计表），等于在已有锁基础上叠加新锁请求，锁持有时间被隐式拉长 -
BEFORE INSERT只能修改NEW字段值，不产生额外 DML，也就不会引入新锁（除非你主动写SELECT FOR UPDATE） - 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，在REPEATABLE READ隔离下会锁住整个时间区间 - 调用存储过程，除非该过程明确声明只读、无任何 DML，否则锁路径不可控
真正有效的排查动作清单
别一上来就调 innodb_lock_wait_timeout 或加重试，优先做这几件事：
- 对触发器内每条 DML，用真实参数模拟执行
EXPLAIN FORMAT=TRADITIONAL，例如EXPLAIN SELECT * FROM product_stock WHERE sku_code = 'ABC123' FOR UPDATE，重点看type字段：出现ALL或index必须建索引 - 把隔离级别从
REPEATABLE READ降到READ COMMITTED，能大幅削弱间隙锁影响；单会话测试用SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，全局生效需改my.cnf并重启 - 禁止触发器内跨表 DML 和同一表自更新；砍掉嵌套触发器（A → B → C），锁路径会彻底失控
- 应用层必须捕获错误码
1213并重试，但仅限幂等操作（如扣减库存、更新状态）；非幂等操作（如插入流水）需配合唯一索引或业务去重
复杂点在于：触发器不是独立模块，它是主事务的延伸。你看到的锁等待，往往不是某条 SQL 卡住了，而是它背后那个没走索引的 UPDATE 正在锁住整张表——而这条语句，连应用日志都不会记。
