触发器不能防止死锁反而易引发死锁因其隐式执行、不可控加锁顺序应显式统一锁序、缩短事务生命周期并用定时任务或CDC替代触发器。死锁不是触发器能防住的它只会让问题更隐蔽触发器不能防止死锁反而常是死锁的帮凶。数据库加锁发生在语句执行时而触发器在语句内部自动触发、隐式开启新语句相当于把多个表的锁请求塞进同一事务里还无法控制顺序——这正是死锁高发场景。真正该做的显式控制锁顺序 缩短事务生命周期死锁本质是多个事务以不同顺序争抢相同资源。解决核心就两条所有事务按固定表顺序加锁让 UPDATE/DELETE 尽早完成别拖着事务干别的。统一约定修改顺序比如总是先 UPDATE users再 UPDATE orders最后 UPDATE logs跨服务也要对齐这个顺序避免在事务里调用 HTTP 请求、生成 PDF、发邮件等耗时操作——这些会让持有锁的时间从毫秒拉长到秒级读已提交READ COMMITTED隔离级别下普通 SELECT 不加锁但 SELECT ... FOR UPDATE 会务必确认是否真需要锁用 SHOW ENGINE INNODB STATUS 查最近死锁详情重点关注 WAITING FOR THIS LOCK TO BE GRANTED 和 HOLDS THE LOCK(S) 两段它们直接暴露了谁锁了什么、谁在等什么触发器为什么容易引发死锁触发器执行不可见、不可控且默认复用当前事务上下文。一个看似简单的 INSERT INTO orders若带 AFTER INSERT 触发器去更新 users 余额就等于在同一个事务里按「orders → users」顺序加锁而另一处业务代码显式按「users → orders」更新冲突就定了。 RedClaw 百度推出的手机端万能AI Agent助手