mysql触发器不直接导致死锁，但会放大锁冲突风险；典型链路是主事务与触发器跨表操作形成abba锁序，尤其在无索引、间隙锁或嵌套触发器场景下；应通过索引优化、降隔离级别、显式锁序及业务层重构来防控。
MySQL触发器本身不直接参与死锁，但它在事务内隐式执行时会放大锁冲突风险——尤其当触发器内含 UPDATE/SELECT FOR UPDATE、跨表操作或未走索引的 WHERE 条件时，极易和主 SQL 形成 ABBA 锁序或锁范围膨胀。高并发下死锁频发，核心不是“关掉触发器”，而是切断它引发的锁链传导。
触发器导致死锁的典型链路
常见于库存扣减、余额变更等场景：主事务 UPDATE 一条订单记录 → 触发器自动 UPDATE 关联的 product_stock 表 → 若 product_stock 上无 product_id 索引，InnoDB 会加全表间隙锁；同时另一事务正按相反顺序（先 product_stock 再 order）操作，瞬间形成循环等待。
关键特征：SHOW ENGINE INNODB STATUS 中能看到两个事务都卡在触发器涉及的表上，且锁模式为 X locks rec but not gap 或更危险的 X locks gap before rec。
- 触发器执行发生在主事务上下文中，共享同一事务 ID 和锁生命周期
- 触发器中 SQL 若未命中索引，会将行锁升级为范围锁甚至表锁
- 触发器逻辑若包含子查询或 JOIN，可能意外锁定多行，扩大锁粒度
必须检查的触发器 SQL 执行计划
别只看触发器定义，要实际 EXPLAIN 它内部每条 DML：
对触发器里所有 UPDATE、DELETE、SELECT ... FOR UPDATE 语句，用真实参数模拟执行并加 EXPLAIN FORMAT=TRADITIONAL。重点确认：
- 是否走了预期索引？
key字段是否非NULL - 是否出现
type: ALL或type: index（全索引扫描）？这是锁爆炸的前兆 -
rows估算值是否远超实际影响行数？说明优化器误判，可能加了不该加的间隙锁
例如：EXPLAIN SELECT * FROM product_stock WHERE sku_code = 'ABC123' FOR UPDATE; 若返回 type: ALL，立刻建 INDEX idx_sku_code ON product_stock(sku_code)。
隔离级别调低到 READ COMMITTED 的真实效果
在 RR（可重复读）下，InnoDB 默认启用间隙锁（Gap Lock），而触发器中范围条件（如 WHERE status IN ('pending', 'processing')）会锁住整个区间，大幅提高死锁概率。切到 READ COMMITTED 后：
- 间隙锁仅在唯一索引等极少数场景保留，普通非唯一条件不再加 Gap Lock
- 触发器内
UPDATE ... WHERE category_id = 5不再锁住 category_id=5 前后所有空隙，只锁匹配行 - 代价是可能产生不可重复读，但对库存、日志、统计类业务通常可接受
设置方式：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;（应用层连接池初始化时统一配置，勿在事务中动态改）。
锁顺序统一：从源头掐断 ABBA
触发器无法控制外部事务的锁顺序，但你可以强制主事务和触发器共用同一把“锁钥匙”：
- 在主 SQL 执行前，显式用
SELECT ... FOR UPDATE按固定顺序锁定所有相关记录（包括触发器要动的那张表的行） - 例如：订单更新前，先
SELECT id FROM product_stock WHERE product_id IN (1001,1002) ORDER BY product_id FOR UPDATE;—— 这个ORDER BY就是锁序契约 - 触发器内后续 UPDATE 必然复用已有锁，不会申请新锁，彻底规避 ABBA
注意：该 SELECT 必须在事务开始后、任何 DML 前执行，且 WHERE 条件要覆盖触发器所有可能操作的行。
真正难处理的，是触发器嵌套调用 + 动态拼接 SQL 的场景——这种设计会让锁行为完全不可预测。与其花时间分析死锁日志，不如把触发器逻辑提到应用层，用明确的锁顺序和重试机制兜底。
