共计 5371 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章主要介绍“INSERT 语句引发的死锁实例分析”，在日常操作中，相信很多人在 INSERT 语句引发的死锁实例分析问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”INSERT 语句引发的死锁实例分析”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
两条一样的 INSERT 语句竟然引发了死锁，这究竟是人性的扭曲，还是道德的沦丧，让我们不禁感叹一句：卧槽！这也能死锁，然后眼中含着悲催的泪水无奈的改起了业务代码。
好的，在深入分析为啥两条一样的 INSERT 语句也会产生死锁之前，我们先介绍一些基础知识。
准备一下环境
为了故事的顺利发展，我们新建一个用了无数次的 hero 表：
CREATE TABLE hero (
number INT AUTO_INCREMENT,
name VARCHAR(100),
country varchar(100),
PRIMARY KEY (number),
UNIQUE KEY uk_name (name)
) Engine=InnoDB CHARSET=utf8;然后向这个表里插入几条记录：
INSERT INTO hero VALUES
(1, l 刘备 , 蜀),
(3, z 诸葛亮 , 蜀),
(8, c 曹操 , 魏),
(15, x 荀彧 , 魏),
(20, s 孙权 , 吴 现在 hero 表就有了两个索引（一个唯一二级索引，一个聚簇索引），示意图如下：
INSERT 语句如何加锁
读过《MySQL 是怎样运行的：从根儿上理解 MySQL》的小伙伴肯定知道，INSERT 语句在正常执行时是不会生成锁结构的，它是靠聚簇索引记录自带的 trx_id 隐藏列来作为隐式锁来保护记录的。
但是在一些特殊场景下，INSERT 语句还是会生成锁结构的，我们列举一下：
1. 待插入记录的下一条记录上已经被其他事务加了 gap 锁时
每插入一条新记录，都需要看一下待插入记录的下一条记录上是否已经被加了 gap 锁，如果已加 gap 锁，那 INSERT 语句应该被阻塞，并生成一个插入意向锁。
比方说对于 hero 表来说，事务 T1 运行在 REPEATABLE READ（后续简称为 RR，后续也会把 READ COMMITTED 简称为 RC）隔离级别中，执行了下边的语句：
# 事务 T1
mysql BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql SELECT * FROM hero WHERE number 8 FOR UPDATE;
+--------+------------+---------+
| number | name | country |
+--------+------------+---------+
| 1 | l 刘备 | 蜀 |
| 3 | z 诸葛亮 | 蜀 |
+--------+------------+---------+
2 rows in set (0.02 sec)这条语句会对主键值为 1、3、8 的这 3 条记录都添加 X 型 next-key 锁，不信的话我们使用 SHOW ENGINE INNODB STATUS 语句看一下加锁情况，图中箭头指向的记录就是 number 值为 8 的记录：
小贴士：
至于 SELECT、DELETE、UPDATE 语句如何加锁，我们已经在之前的文章中分析过了，这里就不再赘述了。
此时事务 T2 想插入一条主键值为 4 的聚簇索引记录，那么 T2 在插入记录前，首先要定位一下主键值为 4 的聚簇索引记录在页面中的位置，发现主键值为 4 的下一条记录的主键值是 8，而主键值是 8 的聚簇索引记录已经被添加了 gap 锁（next-key 锁包含了正经记录锁和 gap 锁），那么事务 1 就需要进入阻塞状态，并生成一个类型为插入意向锁的锁结构。
我们在事务 T2 中执行一下 INSERT 语句验证一下：
mysql BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql INSERT INTO hero VALUES(4, g 关羽 , 蜀 此时 T2 进入阻塞状态，我们再使用 SHOW ENGINE INNODB STATUS 看一下加锁情况：
可见 T2 对主键值为 8 的聚簇索引记录加了一个插入意向锁（就是箭头处指向的 lock_mode X locks gap before rec insert intention），并且处在 waiting 状态。
好了，验证过之后，我们再来看看代码里是如何实现的：
lock_rec_insert_check_and_lock 函数用于看一下别的事务是否阻止本次 INSERT 插入，如果是，那么本事务就给被别的事务添加了 gap 锁的记录生成一个插入意向锁，具体过程如下：
小贴士：
lock_rec_other_has_conflicting 函数用于检测本次要获取的锁和记录上已有的锁是否有冲突，有兴趣的同学可以看一下。
2. 遇到重复键时
如果在插入新记录时，发现页面中已有的记录的主键或者唯一二级索引列与待插入记录的主键或者唯一二级索引列值相同（不过可以有多条记录的唯一二级索引列的值同时为 NULL，这里不考虑这种情况了），此时插入新记录的事务会获取页面中已存在的键值相同的记录的锁。
如果是主键值重复，那么：
当隔离级别不大于 RC 时，插入新记录的事务会给已存在的主键值重复的聚簇索引记录添加 S 型正经记录锁。
当隔离级别不小于 RR 时，插入新记录的事务会给已存在的主键值重复的聚簇索引记录添加 S 型 next-key 锁。
如果是唯一二级索引列重复，那不论是哪个隔离级别，插入新记录的事务都会给已存在的二级索引列值重复的二级索引记录添加 S 型 next-key 锁，再强调一遍，加的是 next-key 锁！加的是 next-key 锁！加的是 next-key 锁！这是 rc 隔离级别中为数不多的给记录添加 gap 锁的场景。
小贴士：
本来设计 InnoDB 的大叔并不想在 RC 隔离级别引入 gap 锁，但是由于某些原因，如果不添加 gap 锁的话，会让唯一二级索引中出现多条唯一二级索引列值相同的记录，这就违背了 UNIQUE 约束。所以后来设计 InnoDB 的大叔就很不情愿的在 RC 隔离级别也引入了 gap 锁。
我们也来做一个实验，现在假设上边的 T1 和 T2 都回滚了，现在将隔离级别调至 RC，重新开启事务进行测试。
mysql SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.01 sec)
# 事务 T1
mysql BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql INSERT INTO hero VALUES(30, x 荀彧 , 魏
ERROR 1062 (23000): Duplicate entry x 荀彧 for key uk_name然后执行 SHOW ENGINE INNODB STATUS 语句看一下 T1 加了什么锁：
可以看到即使现在 T1 的隔离级别为 RC，T1 仍然给 name 列值为 x 荀彧 的二级索引记录添加了 S 型 next-key 锁（图中红框中的 lock mode S）。
如果我们的 INSERT 语句还带有 ON DUPLICATE KEY… 这样的子句，如果遇到主键值或者唯一二级索引列值重复的情况，会对 B + 树中已存在的相同键值的记录加 X 型锁，而不是 S 型锁（不过具体锁的具体类型是和前面描述一样的）。
好了，又到了看代码求证时间了，我们看一下吧：
row_ins_scan_sec_index_for_duplicate 是检测唯一二级索引列值是否重复的函数，具体加锁的代码如下所示：
如上图所示，在遇到唯一二级索引列重复的情况时：
1 号红框表示对带有 ON DUPLICATE … 子句时的处理方案，具体就是添加 X 型锁。
2 号红框表示对正常 INSERT 语句的处理方案，具体就是添加 S 型锁。
不过不论是那种情况，添加的 lock_typed 的值都是 LOCK_ORDINARY，表示 next-key 锁。
在主键重复时 INSERT 语句的加锁代码我们就不列举了。
3. 外键检查时
当我们向子表中插入记录时，我们分两种情况讨论：
当子表中的外键值可以在父表中找到时，那么无论当前事务是什么隔离级别，只需要给父表中对应的记录添加一个 S 型正经记录锁就好了。
当子表中的外键值在父表中找不到时：那么如果当前隔离级别不大于 RC 时，不对父表记录加锁；当隔离级别不小于 RR 时，对父表中该外键值所在位置的下一条记录添加 gap 锁。
死锁要出场了
好了，基础知识预习完了，该死锁出场了。
看下边这个平平无奇的 INSERT 语句：
INSERT INTO hero(name, country) VALUES(g 关羽 , 蜀), (d 邓艾 , 魏 这个语句用来插入两条记录，不论是在 RC，还是 RR 隔离级别，如果两个事务并发执行它们是有一定几率触发死锁的。为了稳定复现这个死锁，我们把上边一条语句拆分成两条语句：
INSERT INTO hero(name, country) VALUES( g 关羽 , 蜀
INSERT INTO hero(name, country) VALUES(d 邓艾 , 魏 拆分前和拆分后起到的作用是相同的，只不过拆分后我们可以人为的控制插入记录的时机。如果 T1 和 T2 的执行顺序是这样的：
也就是：
T1 先插入 name 值为 g 关羽的记录，可以插入成功，此时对应的唯一二级索引记录被隐式锁保护，我们执行 SHOW ENGINE INNODB STATUS 语句，发现啥一个行锁（row lock）都没有（因为 SHOW ENGINE INNODB STATUS 不显示隐式锁）：
接着 T2 也插入 name 值为 g 关羽的记录。由于 T1 已经插入 name 值为 g 关羽的记录，所以 T2 在插入二级索引记录时会遇到重复的唯一二级索引列值，此时 T2 想获取一个 S 型 next-key 锁，但是 T1 并未提交，T1 插入的 name 值为 g 关羽的记录上的隐式锁相当于一个 X 型正经记录锁（RC 隔离级别），所以 T2 向获取 S 型 next-key 锁时会遇到锁冲突，T2 进入阻塞状态，并且将 T1 的隐式锁转换为显式锁（就是帮助 T1 生成一个正经记录锁的锁结构）。这时我们再执行 SHOW ENGINE INNODB STATUS 语句：
可见，T1 持有的 name 值为 g 关羽的隐式锁已经被转换为显式锁（X 型正经记录锁，lock_mode X locks rec but not gap）；T2 正在等待获取一个 S 型 next-key 锁（lock mode S waiting）。
接着 T1 再插入一条 name 值为 d 邓艾的记录。在插入一条记录时，会在页面中先定位到这条记录的位置。在插入 name 值为 d 邓艾的二级索引记录时，发现现在页面中的记录分布情况如下所示：
很显然，name 值为 d 邓艾 的二级索引记录所在位置的下一条二级索引记录的 name 值应该是 g 关羽（按照汉语拼音排序）。那么在 T1 插入 name 值为 d 邓艾的二级索引记录时，就需要看一下 name 值为 g 关羽 的二级索引记录上有没有被别的事务加 gap 锁。
有同学想说：目前只有 T2 想在 name 值为 g 关羽 的二级索引记录上添加 S 型 next-key 锁（next-key 锁包含 gap 锁），但是 T2 并没有获取到锁呀，目前正在等待状态。那么 T1 不是能顺利插入 name 值为 g 关羽 的二级索引记录么？
我们看一下执行结果：
# 事务 T2
mysql INSERT INTO hero(name, country) VALUES( g 关羽 , 蜀
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
很显然，触发了一个死锁，T2 被 InnoDB 回滚了。
这是为啥呢？T2 明明没有获取到 name 值为 g 关羽 的二级索引记录上的 S 型 next-key 锁，为啥 T1 还不能插入入 name 值为 d 邓艾的二级索引记录呢？
这我们还得回到代码上来，看一下插入新记录时是如何判断锁是否冲突的：
看一下画红框的注释，意思是：只要别的事务生成了一个显式的 gap 锁的锁结构，不论那个事务已经获取到了该锁 (granted)，还是正在等待获取（waiting），当前事务的 INSERT 操作都应该被阻塞。
回到我们的例子中来，就是 T2 已经在 name 值为 g 关羽 的二级索引记录上生成了一个 S 型 next-key 锁的锁结构，虽然 T2 正在阻塞（尚未获取锁），但是 T1 仍然不能插入 name 值为 d 邓艾的二级索引记录。
这样也就解释了死锁产生的原因：
T1 在等待 T2 释放 name 值为 g 关羽 的二级索引记录上的 gap 锁。
T2 在等待 T1 释放 name 值为 g 关羽 的二级索引记录上的 X 型正经记录锁。
两个事务相互等待对方释放锁，这样死锁也就产生了。
怎么解决这个死锁问题？
两个方案：
方案一：一个事务中只插入一条记录。
方案二：先插入 name 值为 d 邓艾 的记录，再插入 name 值为 g 关羽 的记录
到此，关于“INSERT 语句引发的死锁实例分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
