mysql死锁是如何产生的_mysql死锁原因分析-mysql教程-PHP中文网

mysql死锁是如何产生的_mysql死锁原因分析

P粉602998670

发布： 2025-12-22 14:37:02

原创

795人浏览过

MySQL死锁本质是多个事务因加锁顺序不一致陷入循环等待，需同时满足互斥、请求并保持、不可剥夺、循环等待四条件；常见于加锁顺序不一、间隙锁冲突、索引失效及主键与二级索引混用等场景。

mysql死锁是如何产生的_mysql死锁原因分析

MySQL死锁本质是多个事务因加锁顺序不一致，陷入互相等待的循环依赖状态。InnoDB 会自动检测并回滚其中一个事务（报错 ERROR 1213: Deadlock found when trying to get lock），但理解成因才能真正规避。

死锁不是偶然现象，它必须同时具备以下四点：

这些业务操作模式最容易踩坑：

Google Antigravity

谷歌推出的AI原生IDE，AI智能体协作开发

277

加锁顺序不一致：事务 A 先 update id=5 再 update id=3；事务 B 反过来先 id=3 后 id=5 —— 最典型死锁来源
范围查询引发间隙锁冲突：where age between 20 and 30 触发 gap lock，不同事务扫描重叠区间时可能锁住相同间隙
索引失效导致锁升级：本该走索引却全表扫描，把行锁扩大为大量行锁甚至隐式锁升级，增加碰撞概率
混合使用主键与二级索引：事务 A 用 name=xxx（二级索引）更新，事务 B 直接用主键 id 更新同一行 —— 两者加锁路径不同（先二级索引再聚簇索引 vs 直接聚簇索引），易形成交叉等待

很多死锁看似随机，其实有底层机制可循：

InnoDB 的 next-key lock = 行锁 + 前隙锁，在 RR 隔离级别下默认启用，是范围查询死锁的主因
唯一索引上的等值查询（如 where id=100）只加记录锁（record lock），不加间隙锁；但非唯一索引或范围条件就会锁住间隙
SELECT ... FOR UPDATE / LOCK IN SHARE MODE 的执行顺序直接影响加锁顺序，尤其搭配 IN 子句时 —— MySQL 会对 in 列表自动排序后加锁（如 in (5,1,3) 实际按 1→3→5 加锁），这是可控的突破口
长事务持有锁时间越长，与其他事务发生竞争的窗口越大，即使逻辑简单也容易卷入死锁

别只看报错，要抓关键证据：

执行 SHOW ENGINE INNODB STATUS\G，重点关注 LATEST DETECTED DEADLOCK 区块，里面明确写出哪两个事务、各自持有哪些锁、正在等待什么锁
检查事务中 SQL 的执行顺序、WHERE 条件是否走索引、是否含范围查询或 OR 条件
确认应用层是否对同一批数据做了无序的 for update 操作（如随机分配场景中借款人 ID 未排序）

以上就是mysql死锁是如何产生的_mysql死锁原因分析的详细内容，更多请关注php中文网其它相关文章！