MySQL触发器处理死锁的防范方法_MySQL高并发触发器优化

触发器中避免跨表写操作、禁止SELECT...FOR UPDATE、不依赖MAX(id)等自增推导，推荐应用层异步处理或预分配ID，并通过死锁日志和performance_schema定位问题。触发器里别碰其他表的写操作死锁在触发器里爆发，八成是因为它偷偷去改了别的表。比如 INSERT 一个订单后，触发器顺手去 UPDATE 库存表，而另一条事务正相反------先锁库存再插订单，两边一卡，就 deadlock 了。实操建议：触发器逻辑尽量只操作当前表（NEW 和 OLD 所属的表），避免 UPDATE/DELETE 其他表真要联动更新，改用应用层异步处理（比如发 MQ 消息），或退一步用延迟写入（如插入到日志表，由定时任务批量处理）查 SHOW ENGINE INNODB STATUS 时重点看 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 后面是不是跨表锁避免在触发器中调用存储函数或复杂子查询看起来只是读个配置值，但万一那个 SELECT 带了 FOR UPDATE 或命中了没索引的字段，就会拉长锁持有时间，提高死锁概率。实操建议：触发器内禁止出现 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE所有读操作必须走覆盖索引；如果要查配置，优先用常量或应用层缓存，而不是实时查 config_table用 EXPLAIN 确认触发器里每个 SELECT 的 type 是 const 或 ref，不是 ALL 或 indexINSERT 触发器慎用 BEFORE INSERT + 自增主键依赖当多个并发 INSERT 都在 BEFORE INSERT 里试图读取 MAX(id) 或调用 LAST_INSERT_ID()，很容易因为间隙锁（gap lock）互相阻塞，尤其在可重复读隔离级别下。 唱鸭 音乐创作全流程的AI自动作曲工具，集 AI 辅助作词、AI 自动作曲、编曲、混音于一体