INSERT语句引发的死锁

两条一样的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的记录：