记录一次MySQL死锁的分析与解决过程

最新推荐文章于 2025-07-02 22:33:16 发布

是Guava不是瓜娃

最新推荐文章于 2025-07-02 22:33:16 发布

阅读量4w

点赞数 33

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/noaman_wgs/article/details/82529908

本文详述了一次MySQL死锁的分析过程，从死锁的定义、MySQL的锁种类，特别是插入意向锁和临键锁，到死锁发生的条件和解决方法，如wait-for graph。通过具体的例子解析了事务间的等待图，展示了如何查看MySQL死锁日志，并通过SQL语句分析了死锁产生的原因，最后提出了解决方案，强调了创建区分度更高的索引以避免死锁。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、问题描述

上周开发过程中，线下环境遇到一个死锁问题，借此机会正好分析下MySQL死锁的原因和解决方案，本篇文章会带你去如何查看死锁日志和分析、解决。
这里写图片描述

二、MySQL死锁介绍

1、MySQL 锁种类

MySQL InnoDB存储引擎提供了如下几种锁：

（1）共享/排他锁（S/X锁）

共享锁（S Lock）：允许事务读取一行数据，多个事务可以拿到一把S锁（即读读并行）；
排他锁（X Lock）：允许事务删除或更新一行数据，多个事务有且只有一个事务可以拿到X锁（即写写/写读互斥）；

（2）意向锁（Intention Lock）
意向锁是一种表级别的锁，意味着事务在更细的粒度上进行加锁。

意向共享锁（IS Lock）：事务想要获得一张表中某几行的共享锁；
意向排他锁（IX Lock）：事务想要获得一张表中某几行的排他锁；

举个例子，事务1在表1上加了S锁后，事务2想要更改某行记录，需要添加IX锁，由于不兼容，所以需要等待S锁释放；如果事务1在表1上加了IS锁，事务2添加的IX锁与IS锁兼容，就可以操作，这就实现了更细粒度的加锁。

（3）插入意向锁（Insert Intention Lock）
插入意向锁是间隙锁的一种，专门针对insert操作的。即多个事务在同一个索引、同一个范围区间内插入记录时，如果插入的位置不冲突，则不会阻塞彼此；
举个例子：在可重复读隔离级别下，对PK ID为10-20的数据进行操作：
事务1在10-20的记录中插入了一行：
insert into table value(11, xx)
事务2在10-20的记录中插入了一行：
insert into table value(12, xx)
由于两条插入的记录不冲突，所以会使用插入意向锁，且事务2不会被阻塞。

（4）自增锁（Auto-inc Locks）
自增锁是一种特殊的表级别锁，专门针对事务插入AUTO-INCREMENT类型的列。
即一个事务正在往表中插入记录时，其他事务的插入必须等待，以便第1个事务插入的行得到的主键值是连续的。
举个例子：在可重复读隔离级别下，PK ID为自增主键
表中已有主键ID为1、2、3的3条记录。
事务1插入了一行：
insert into table value('aa')
得到一条（4,’aa’）的记录，未提交；

此时
事务2中插入了一行：
insert into table value('bb')
这时会被阻塞，即用到了插入意向锁的概念。

（5）记录锁（Record Locks）- locks rec but not gap
记录锁是的单个行记录上的锁，会阻塞其他事务对其插入、更新、删除；

（6）间隙锁(Gap Lock)
间隙锁锁定记录的一个间隔，但不包含记录本身。
举个例子：
假如数据库已有ID为1、6两条记录，
现在想要在ID in （4，10）之间更新数据的时候，会加上间隙锁，锁住[4,5] [7,10] ,(不包含已有记录ID=5本身)
那么在更新ID=5的记录（只有一条记录）符合条件；
如果不加间隙锁，事务2有可能会在4、10之间插入一条数据，这个时候事务1再去更新，发现在(4,10)这个区间内多出了一条“幻影”数据。
间隙锁就是防止其他事务在间隔中插入数据，以导致“不可重复读”。

（7）临键锁（Next-Key Lock）= Gap Lock + Record Lock
临建锁是记录锁与间隙锁的组合，即：既包含索引记录，又包含索引区间，主要是为了解决幻读。

2、MySQL死锁

死锁是指两个或两个以上事务在执行过程中因争抢锁资源而造成的互相等待的现象。

发生死锁的3个条件

>= 2个事务
不同方向
相同锁资源

解决死锁的方法

超时等待：即当两个事务互相等待时，当一个事务等待时间超过设置的阈值时，就将其回滚，另外事务继续进行。（缺点：如果回滚的事务更新了很多行，占用了较多的undo log，那么在回滚的时候花费的时间比另外一个正常执行的事务花费的时间可能还要多，就不太合适）；
wait-for graph（等待图）：死锁碰撞检测，是一种较为主动的死锁检测机制，要求数据库保存锁的信息链表和事务等待链表两部分信息，通过这两个部分信息构造出一张图，在每个事务请求锁并发生等待时都会判断是否存在回路，如果在图中检测到回路，就表明有死锁产生，这时候InnoDB存储引擎会选择回滚undo量最小的事务。

下面举个例子简单介绍下对wait-for graph的理解。
如下图所示，有4个事务T1、T2、T3、T4，由图2可以得出T2对row1占用x锁；由图3得出T1对row2占用s锁（遵循FIFO原则，链表最上层先拿到锁资源，故T2、T1分别占有row1、row2的锁资源）。

现在：
（1）T1想要占用row1的s锁，T1需要等待T2的x锁释放（图1、2）