你在MySQL中加了什么锁，导致死锁的？

前言

最近在看 了篇文章，讲的MySQL加了什么锁，导致死锁的，自己也跟着做了做，题目如下图：

​其实基础好的友友们，一眼就能看出会发生死锁，不懂的友友们也不要气馁，听我细细分析；

实验的 MySQL 版本是 8.0.21，；

如果友友们对 MySQL 的锁不太了解，又没有什么好的资源的话，推荐看看小林写的 MySQL 锁篇；

准备

新建一张 t_student 表，只有 id字段是主键字段，其他都是普通字段；

CREATE TABLE `t_student` ( `id` int NOT NULL, `no` varchar(255) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, `age` int DEFAULT NULL, `score` int DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 复制代码

填充相关数据，最终，t_student 表的记录如下所示：

开始

在实验开始前，再次声明一下实验环境：

• MySQL 版本：8.0.21

• 隔离级别：可重复读（RR）

• Navicat：12

启动两个事务，按照题目的 SQL 执行顺序，过程如下表格：

​可以看到，事务 A 和 事务 B 都在执行 insert 语句后，都陷入了等待状态（前提没有打开死锁检测），也就是发生了死锁，因为都在相互等待对方释放锁。

原因

为什么会发生死锁？

可以通过下面这条 SQL 语句来查看事务执行 SQL 的过程中，到底加了什么锁：

SELECT * FROM performance_schema.data_locks 复制代码

接下来，我们就一起来分析一下每一条 SQL 语句执行之后所加的锁；

Time 1 阶段

Time 1 阶段，事务 A 执行以下语句：

# 事务 A BEGIN > OK > 时间: 0s update t_student set score = 100 where id = 25 > Affected rows: 0 > 时间: 0s 复制代码

然后执行上述的锁查询语句，查看事务 A 此时加了什么锁，这里的话，有针对性的选择了几个输出，

SELECT `ENGINE`, `ENGINE_TRANSACTION_ID`, `LOCK_TYPE`, `LOCK_MODE`, `LOCK_STATUS`, `LOCK_DATA` FROM performance_schema.data_locks 复制代码

​从上图可以看到，共加了两个锁，分别是：

• 表锁：X 类型的意向锁；

• 行锁：X 类型的间隙锁；

这里我们重点关注行锁，图中 LOCK_TYPE 中的 RECORD 表示行级锁，而不是记录锁的意思，通过 LOCK_MODE 可以确认是 next-key 锁，还是间隙锁，还是记录锁：

• 如果 LOCK_MODE 为 X，说明是 next-key 锁；

• 如果 LOCK_MODE 为 X, REC_NOT_GAP，说明是记录锁；

• 如果 LOCK_MODE 为 X, GAP，说明是间隙锁；

因此，此时事务 A 在主键索引（INDEX_NAME : PRIMARY）上加的是间隙锁，锁范围是 (20, 30)。

间隙锁的范围 (20, 30) ，是怎么确定的？

其实这是可以根据经验推断出来的，如果 LOCK_MODE 是 next-key 锁或者间隙锁，那么 LOCK_DATA 就表示锁的范围最右值，此次的事务 A 的 LOCK_DATA 是 30。

然后锁范围的最左值是 t_student 表中 id 为 30 的上一条记录的 id 值，即 20。因此，间隙锁的范围 (20, 30)。

​这里的话，我们可以再通过两个小实验来验证一下：

• 在当前 t_student 表中的第一条记录前进行更新：

• update t_student set score = 21 where id = 10; > Affected rows: 0 > 时间: 0s 复制代码

• 通过对当前记录的锁分析，可以发现，加的依旧是 X 型间隙锁，同时，Lock_DATA 的值为15，即间隙锁的范围是 (10,15)：

• 在当前 t_student 表中的最后一条记录后进行更新：

• update t_student set score = 21 where id = 99 > Affected rows: 0 > 时间: 0s 复制代码

• 通过对当前记录的锁分析，可以发现，只加了一个 X 锁， LOCK_DATA 的值为 supremum pseudo-record，相当于比索引中所有值都大，但却不存在索引中，也可以视为最后一行之后的间隙锁；

• For the last interval, the next-key lock locks the gap above the largest value in the index and the “supremum”pseudo-record having a value higher than any value actually in the index. The supremum is not a real index record, so, in effect, this next-key lock locks only the gap following the largest index value.

通过上述的两个小实验，不难发现，一般情况下，LOCK_DATA 的值代表的是右边的范围边界值；

Time 2 阶段

Time 2 阶段，事务 B 执行以下语句：

# 事务 B BEGIN > OK > 时间: 0s update t_student set score = 100 where id = 26 > Affected rows: 0 > 时间: 0s 复制代码

在执行锁查询语句，来看看事务 B 此时加了什么锁；

​从上图可以看到，行锁是 X 类型的间隙锁，间隙锁的范围是 (20, 30)。

事务 A 和 事务 B 的间隙锁范围都是一样的，为什么不会冲突？

两个事务的间隙锁之间是相互兼容的，不会产生冲突。

在 MySQL 官网上还有一段非常关键的描述：

Gap locks in InnoDB are “purely inhibitive”, which means that their only purpose is to prevent other transactions from Inserting to the gap. Gap locks can co-exist. A gap lock taken by one transaction does not prevent another transaction from taking a gap lock on the same gap. There is no difference between shared and exclusive gap locks. They do not conflict with each other, and they perform the same function.

间隙锁的意义只在于阻止区间被插入，因此是可以共存的。一个事务获取的间隙锁不会阻止另一个事务获取同一个间隙范围的间隙锁，共享（S型）和排他（X型）的间隙锁是没有区别的，他们相互不冲突，且功能相同。

Time 3 阶段

Time 3，事务 A 插入了一条记录：

​此时，事务 A 就陷入了等待状态。

再执行锁查询语句，来看看事务 A 此时加了什么锁导致了阻塞的发生；

​可以看到，事务 A 的状态为等待状态（LOCK_STATUS: WAITING），因为向事务 B 生成的间隙锁（范围 (20, 30)）中插入了一条记录，所以事务 A 的插入操作生成了一个插入意向锁（LOCK_MODE:INSERT_INTENTION）。

插入意向锁是什么？

注意！插入意向锁名字里虽然有意向锁这三个字，但是它并不是意向锁，它属于行级锁，是一种特殊的间隙锁。

在 MySQL 的官方文档中有以下重要描述：

An Insert intention lock is a type of gap lock set by Insert operations prior to row Insertion. This lock signals the intent to Insert in such a way that multiple transactions Inserting into the same index gap need not wait for each other if they are not Inserting at the same position within the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that attempt to Insert values of 5 and 6, respectively, each lock the gap between 4 and 7 with Insert intention locks prior to obtaining the exclusive lock on the Inserted row, but do not block each other because the rows are nonconflicting.

这段话表明尽管插入意向锁是一种特殊的间隙锁，但不同于间隙锁的是，该锁只用于并发插入操作。

如果说间隙锁锁住的是一个区间，那么「插入意向锁」锁住的就是一个点。因而从这个角度来说，插入意向锁确实是一种特殊的间隙锁。

插入意向锁与间隙锁的另一个非常重要的差别是：尽管「插入意向锁」也属于间隙锁，但两个事务却不能在同一时间内，一个拥有间隙锁，另一个拥有该间隙区间内的插入意向锁（当然，插入意向锁如果不在间隙锁区间内则是可以的）。所以，插入意向锁和间隙锁之间是冲突的。

另外补充一点，插入意向锁的生成时机：

每插入一条新记录，都需要看一下待插入记录的下一条记录上是否已经被加了间隙锁，如果已加间隙锁，那 Insert 语句会被阻塞，并生成一个插入意向锁 。

Time 4 阶段

Time 4，事务 B 插入了一条记录：

insert into t_student(id, no, name, age,score) value (26, 'S0026', 'ace', 28, 90) > 1213 - Deadlock found when trying to get lock; try restarting transaction > 时间: 0.008s 复制代码

这里的话，因为做过优化，所以发生死锁时，直接被检测了出来，并且自动回滚了，有些可能是阻塞等待，进入了死锁状态；

通过锁分析也可以得知，事务 B 因为回滚，已经释放了间隙锁，之前事务 A 在 Time 3 阶段阻塞等待的 insert 语句也能够成功执行了：

所以为什么会发生死锁呢？

本次案例中，事务 A 和事务 B 在执行完后 update 语句后都持有范围为(20, 30）的间隙锁，而接下来的插入操作为了获取到插入意向锁，都在等待对方事务的间隙锁释放，于是就造成了循环等待，满足了死锁的四个条件：互斥、占有且等待、不可强占用、循环等待，因此发生了死锁。

总结

两个事务即使生成的间隙锁的范围是一样的，也不会发生冲突，因为间隙锁目的是为了防止其他事务插入数据，因此间隙锁与间隙锁之间是相互兼容的。

在执行插入语句时，如果插入的记录在其他事务持有间隙锁范围内，插入语句就会被阻塞，因为插入语句在碰到间隙锁时，会生成一个插入意向锁，然后插入意向锁和间隙锁之间是互斥的关系。

如果两个事务分别向对方持有的间隙锁范围内插入一条记录，而插入操作为了获取到插入意向锁，都在等待对方事务的间隙锁释放，于是就造成了循环等待，满足了死锁的四个条件：互斥、占有且等待、不可强占用、循环等待，因此发生了死锁。