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