MySQL的触发器并不是一个独立的事务单元，它和外层的触发语句共享同一个事务上下文。这意味着触发器内部执行的每一条SQL所产生的行锁、间隙锁，都会叠加到外层事务的锁持有列表中。当多个并发事务分别通过触发器以不同的顺序访问同一批数据行时，死锁就产生了，而且被回滚的往往是整个外层事务，影响范围远超触发器本身。本文将从锁机制原理出发，详细分析触发器引发死锁的常见场景，并给出锁顺序优化与事务范围控制的完整方案。
一、触发器为什么会放大死锁风险
要理解触发器的死锁问题，首先要明白InnoDB的锁模型。InnoDB在默认的可重复读（REPEATABLE READ）隔离级别下，普通的SELECT不加锁，但UPDATE、DELETE、INSERT语句会对扫描到的记录加排他锁（X锁），并且在索引扫描范围上还会加间隙锁（Gap Lock）。触发器本质上是一组被自动执行的SQL，它们的加锁行为与手工执行完全相同。
触发器放大死锁风险的关键在于锁的持有时间变长了。假设外层事务先更新了表A，触发的触发器又去更新表B和表C，那么这个事务会同时持有A、B、C三张表的锁，直到整个事务提交或回滚。事务范围越大、执行时间越长，与其他事务产生锁冲突的概率就越高。更隐蔽的是，触发器内部的SQL对外层调用者是完全透明的，开发者 review 代码时往往只看业务SQL，忽略了触发器里隐藏的写操作。
看一个典型的死锁案例：订单表有一个AFTER UPDATE触发器，用于更新账户余额表。
-- 触发器定义 DELIMITER $$ CREATE TRIGGER trg_order_after_update AFTER UPDATE ON orders FOR EACH ROW BEGIN -- 余额变动记录 UPDATE account_log SET amount = amount + NEW.qty WHERE account_id = NEW.account_id; -- 更新账户余额（热点行） UPDATE accounts SET balance = balance - NEW.qty WHERE account_id = NEW.account_id; END$$ DELIMITER ; -- 事务1：先更新账户，再更新订单 BEGIN; UPDATE accounts SET balance = balance - 10 WHERE account_id = 1001; UPDATE orders SET status = 'PAID' WHERE order_id = 5001; -- 触发器又要更新 accounts COMMIT; -- 事务2：只更新订单，触发器先锁 account_log 再锁 accounts BEGIN; UPDATE orders SET status = 'PAID' WHERE order_id = 5002; COMMIT;
事务1先锁了accounts表的同一行，再去锁orders，而触发器在更新orders之后又要回头锁accounts。两个事务对这两张表的加锁顺序相反，形成经典的AB-BA死锁。InnoDB的死锁检测器会选择回滚代价较小的事务，但无论是哪个被回滚，业务都会报出Deadlock found when trying to get lock; try restarting transaction错误。
二、统一锁顺序：从设计层面消除循环等待
死锁的四个必要条件中，"循环等待"是最容易被打破的一环。只要让所有事务以固定的全局顺序访问表和行，循环等待就不可能形成。实践中可以约定一个规则：所有涉及多表写入的代码，按照表名的字典序或预先定义的层级顺序加锁。
对于触发器，需要特别注意触发器内部访问的表与外层语句所在表之间的顺序关系。一个实用的原则是：触发器只向上游（被引用的、更基础的表）加锁，不要反向操作外层正在处理的表。例如订单触发器可以更新账户表、库存表，但绝对不要再回头更新订单表本身或其他同级业务表。如果确实存在双向更新的需求，应该把逻辑移到存储过程或应用层，由统一的入口按固定顺序执行。
在行级别上，锁顺序同样重要。典型的场景是触发器内根据某个不唯一的字段批量更新：
-- 危险写法：不同事务扫描行的顺序可能不同 UPDATE inventory SET stock = stock - NEW.qty WHERE warehouse_id = NEW.wh_id; -- 更危险：触发器内按非索引字段排序更新多行 UPDATE points SET score = score + 1 WHERE user_level BETWEEN 1 AND 5;
当更新多条记录时，InnoDB会按照索引的顺序逐行加锁。如果不同事务使用了不同的索引，或者扫描顺序受优化器执行计划影响，加锁顺序就可能不一致。解决办法有两个：一是确保这类批量更新走同一个索引，二是改为先按主键排序查出目标行，再逐行更新，保证所有事务按主键升序加锁。此外，务必给WHERE条件中的字段加上索引——如果没有索引，UPDATE会锁住全表扫描路径上的所有行，死锁和锁等待会急剧增加。
三、缩小事务范围：让锁尽早释放
除了锁顺序，锁的持有时间是另一个可以优化的维度。触发器与外层语句同生共死，因此外层事务越短，触发器持有的锁也越快释放。很多死锁问题的根源不是触发器本身，而是外层事务把远程调用、文件操作、用户交互等慢操作包裹在了事务内部。
一个常见的反面模式是在事务里调用外部接口：
-- 应用层伪代码：危险的长事务
BEGIN;
UPDATE orders SET status = 'PAID' WHERE order_id = 5001; -- 触发器更新 accounts
CALL http_request('https://api.ipipp.com/notify'); -- 外部调用耗时2秒
UPDATE payments SET settled = 1 WHERE order_id = 5001;
COMMIT;在这2秒内，accounts表上被触发的行一直被锁定，其他事务只要碰到了这批热点账户，就会排队等待甚至死锁。正确的做法是把事务压缩到只包含数据库操作：先在事务外完成所有外部调用和计算，事务内只做写入，并且尽量把多个写操作合并。对于高并发场景，建议开启innodb_deadlock_detect（默认开启）保证死锁能被快速发现，同时合理设置innodb_lock_wait_timeout（默认50秒，高并发下可适当调小到5-10秒），让锁等待尽早失败暴露问题，而不是无限堆积连接。
如果触发器内的逻辑本身比较重（比如要写日志、更新统计），可以考虑异步化：触发器只往一张无热点的队列表INSERT一条消息，由后台任务或定时任务批量消费。这样触发器内的操作变成单表单行插入，几乎不会产生锁冲突，而复杂逻辑在批处理中串行执行，天然没有并发问题。
四、热点行与批量操作的实际优化手段
账户余额、库存扣减、计数器这类热点行更新是触发器死锁的重灾区，因为大量并发事务都争夺同一行记录。即使锁顺序完全一致，热点行也会造成严重的锁等待，吞吐量急剧下降。
针对热点行有几种成熟的缓解方案。第一种是分段账户：把一个账户拆成N个子账户，更新时随机挑选一个，查询余额时聚合求和，将单行锁冲突分散到N行。第二种是累计缓冲：变更量先累加到内存或Redis中，每隔一段时间批量刷回数据库，把上千次单行更新合并为一次更新。第三种是在MySQL 8.0中利用SKIP LOCKED或NOWAIT语法主动跳过被锁定的行，把等待转为快速失败后重试。
另一个方向是减少触发器的执行频次。FOR EACH ROW意味着一条影响1万行的UPDATE会触发1万次触发器执行，每次都产生独立的加锁操作。如果触发器内的逻辑可以聚合，更好的做法是用事件调度器（Event Scheduler）或定时任务做批量汇总，而不是依赖行级触发器。例如库存变动日志，逐行触发记录明细没问题，但统计汇总完全可以每分钟跑一次：
-- 用定时任务替代触发器中的统计更新
CREATE EVENT ev_stock_summary
ON SCHEDULE EVERY 1 MINUTE
DO
UPDATE stock_summary s
JOIN (
SELECT sku_id, SUM(delta) AS total
FROM stock_change_log
WHERE created_at >= NOW() - INTERVAL 1 MINUTE
GROUP BY sku_id
) t ON s.sku_id = t.sku_id
SET s.total_out = s.total_out + t.total;五、死锁的排查与监控
即使做了充分优化，线上仍然可能偶发死锁，因此建立排查手段非常必要。首先要开启死锁日志，确保innodb_print_all_deadlocks参数为ON，这样每一次死锁都会被记录到error log中，而不仅仅是最近一次：
SET GLOBAL innodb_print_all_deadlocks = ON; SHOW VARIABLES LIKE 'innodb_print_all_deadlocks'; -- 查看最近一次死锁信息 SHOW ENGINE INNODB STATUS\G
在死锁日志中，重点看两个事务各自"holds the lock"和"waiting for"的记录：持有哪个锁、等待哪个锁、对应的SQL语句是什么。把死锁日志中的表名、主键值提取出来，对照触发器的定义，通常就能定位到是哪两个加锁顺序发生了交叉。如果怀疑触发器隐含的锁，可以用SHOW ENGINE INNODB STATUS结合performance_schema.data_locks表（MySQL 8.0）实时观察锁的持有情况，验证优化效果。
最后总结几条实践原则：触发器保持轻量，只做单表简单写入，避免嵌套触发和反向更新；所有多表操作遵守统一的加锁顺序，WHERE条件必须有索引；外层事务尽量短，绝不包含慢操作；热点行采用分段或异步缓冲；上线前用并发压测验证，配合死锁日志持续监控。做到这几点，触发器在高并发场景下就能保持稳定，死锁问题基本可以杜绝。