SQL触发器本身不直接导致死锁，但因在主事务中隐式执行，将单条SQL扩展为多表复合锁操作，极易引发循环等待和ABBA锁序；正确做法是BEFORE中用SET NEW赋值避免额外DML，禁用跨表更新与非索引查询，并通过SHOW ENGINE INNODB STATUS中“tables in use >1”及日志表锁痕迹定位问题。
SQL触发器本身不会直接“导致”死锁，但它会让死锁更频繁、更难定位——因为它在主事务中隐式执行，把一条业务SQL悄悄扩展成多张表的锁操作，而这些额外锁完全不出现在应用日志里。
为什么触发器里的UPDATE同一张表会死锁
看似安全的UPDATE orders SET status = 'done' WHERE id = NEW.id，在InnoDB中极易触发循环等待：主事务已对NEW.id所在行持X锁，触发器再发一次相同条件的UPDATE，等于二次申请同一行锁。这不是“重复更新”，而是两次独立的锁请求，中间没有COMMIT隔开。
- 正确做法是用
SET NEW.status = 'done'在BEFORE INSERT/UPDATE中直接赋值，不走额外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 SET status = 'processed' WHERE order_id = NEW.id——这就是触发器执行痕迹
触发器内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里的触发器名；优化时也别幻想靠改隔离级别——那只是掩盖症状，不是切断锁链。
