sql触发器本身不直接导致死锁，但因其在主事务中隐式执行并共享同一事务id和锁生命周期，会将单条sql扩展为“主语句+多条触发逻辑”的复合锁操作；只要触发器内含update、select for update或跨表dml，死锁概率就陡增。
SQL触发器本身不直接导致死锁，但它在主事务中隐式执行、共享同一事务ID和锁生命周期，会把单条SQL变成“主语句 + 多条触发逻辑”的复合锁操作——只要触发器里有UPDATE、SELECT FOR UPDATE或跨表DML，死锁概率就陡增。
触发器内UPDATE同一张表为什么会死锁
看似安全的“自己改自己”，在InnoDB中极易触发循环等待：主事务已对NEW.id所在行持X锁，触发器再发一条UPDATE t1 SET status = 'done' WHERE id = NEW.id，就是二次申请同一行锁。
- 正确做法是用
SET NEW.status = 'done'在BEFORE触发器中直接赋值，不走额外SQL - 若需更新多字段（如订单状态+子表计数），必须剥离出触发器，交由应用层异步完成
- 真要在数据库侧维护统计值，可用
INSERT INTO summary_log写日志表（引擎选BLACKHOLE），再由定时任务批量聚合
如何用SHOW ENGINE INNODB STATUS定位触发器死锁
死锁发生后立刻执行SHOW ENGINE INNODB STATUS\G，重点看LATEST DETECTED DEADLOCK区块里的三类线索：
- 查
TRANSACTION段中是否出现类似mysql tables in use 2, locked 2——数字大于1表明涉及多表，大概率有触发器参与 - 比对
HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED中的锁模式，若其中一把锁来自t_log或audit_history这类日志表，基本可判定是触发器行为 - 注意
INSERT INTO t_order后紧跟着UPDATE t_log的堆栈顺序——这就是触发器执行痕迹
触发器内DML必须满足的索引与执行计划要求
触发器里一条没走索引的UPDATE product_stock SET qty = qty - 1 WHERE sku_code = 'ABC123'，在RR隔离级别下可能升级为全表间隙锁；而另一事务按相反顺序操作，ABBA锁序瞬间形成。
- 对触发器内每条DML，用真实参数模拟执行并加
EXPLAIN FORMAT=TRADITIONAL，确认是否走了预期索引 - 所有读操作必须命中覆盖索引：用
EXPLAIN确认type是const或ref，不能是ALL或index - 禁用
WHERE status = 'pending'这类范围条件，它会触发gap lock；统一用主键或唯一索引更新
真正危险的不是触发器存在，而是它让锁路径变得不可见——你很难从应用日志里看出某次INSERT背后悄悄锁了三张表。排查时别只盯错误码1205，得进死锁图XML里找executionStack里的触发器名；优化时也别幻想靠改隔离级别解决，关键在让每条触发逻辑的锁粒度、顺序、索引都确定可控。
