sql触发器本身不直接导致死锁，但因其在主事务中隐式执行、共享锁生命周期，会将单条sql扩展为多表多行的复合锁操作；只要触发器含update、select for update或跨表dml，且未走索引或加锁顺序不一致，就极易引发循环等待与abba死锁。
SQL触发器本身不直接死锁，但它会把单条业务语句悄悄扩展成多表、多行、多锁的复合操作——而这些额外锁完全隐式发生，你从应用日志里根本看不到。死锁频发不是因为“用了触发器”，而是因为触发器让锁路径不可见、不可控、不可预测。
触发器里UPDATE同一张表为什么会立刻死锁
看似安全的UPDATE t1 SET status = 'done' WHERE id = NEW.id，在InnoDB中极易触发循环等待：主事务已对NEW.id所在行持X锁，触发器再发一条相同条件的UPDATE，就是二次申请同一行锁。InnoDB不允许一个事务重复获取同一行的X锁，直接进入等待队列。
- 正确做法是用
SET NEW.status = 'done'在BEFORE INSERT或BEFORE 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或stats_summary这类日志/统计表，90%是触发器行为 - 注意堆栈顺序：如果日志里紧跟着
INSERT INTO t_order之后出现UPDATE t_log SET ... WHERE order_id = NEW.id，这就是触发器执行痕迹
触发器内DML必须满足的索引与执行计划硬要求
一句没走索引的UPDATE product_stock SET qty = qty - 1 WHERE sku_code = 'ABC123'，在RR隔离级别下可能升级为全表间隙锁；而另一事务按相反顺序操作，ABBA锁序瞬间形成。
- 对触发器中每条DML，必须用真实参数模拟执行
EXPLAIN FORMAT=TRADITIONAL，确认type是const或ref，不能是ALL或index - 禁用
WHERE status = 'pending'这类范围条件——它会触发gap lock；统一改用主键或唯一索引更新 - 所有读操作必须命中覆盖索引：例如
SELECT qty FROM stock WHERE sku = NEW.sku，且sku字段必须有唯一索引
真正危险的不是触发器存在，而是它让锁路径变得不可见——你很难从应用日志里看出某次INSERT背后悄悄锁了三张表。排查时别只盯错误码1205，得进死锁图XML里找executionStack里的触发器名；优化时也别幻想靠改隔离级别解决，关键在让每条触发逻辑的锁粒度、顺序、索引都可验证、可收敛。
