最近遇到一个由于唯一性索引，导致并发插入产生死锁的场景，在分析死锁产生的原因时，发现这一块还挺有意思的，涉及到MySql中不少的知识点，特此总结记录一下。
一、MySql常见的锁
谈到mysql的锁，可以说的就比较多了，比如行锁、表锁、页锁、元数据锁等，当然我们这里没打算把所有的都细列出来，我们这里主要针对行锁、gap锁进行拓展，以方便分析第二节中，为什么并发插入同样的数据会产生死锁的问题
0. 锁分类
我们最常说的锁，可以区分为共享锁(S)和排它锁(X)，在mysql的innodb引擎中，为了解决幻读问题，引入了gap锁以及next key lock；除此之外，还有一种意向锁的，比如插入意向锁
本文将主要介绍的以下几种锁
- 行锁(record lock): 请注意它是针对索引的锁（所以如果没有索引时，最终行锁就会导致整个表都会被锁住）
- 共享锁(S Lock): 也叫读锁，共享锁之间不会相互阻塞（顾名思义）
- 排它锁(X Lock): 也叫写锁，排它锁一次只能有一个session（或者说事务？）持有
- 间隙锁(gap lock): 针对索引之间的间隙
- Next-key锁（Next-key lock)：可以简单理解为行锁 + 间隙锁
上面虽然介绍了几种锁的基本定义，但是什么时候是行锁，怎样获取共享锁，排它锁又是在哪些场景下会产生呢？gap lock/next key lock又是怎样解决幻读的呢？
下面所有的都是基于mysql5.7.22 innodb引擎，rr隔离级别进行说明
1.共享锁与排它锁
下表介绍我们的实际使用的sql中，是否会使用锁，以及会产生什么锁
共享锁与排他锁区分
2. 行锁、表锁、gap锁、next-key锁区分
这几个的区分，主要就是看我们最终锁住的效果，比如
- 没有索引，加S/X锁最终都是锁整表 （为啥？因为锁是针对索引而言的）
- 根据主键/唯一键锁定确定的记录：行锁
- 普通索引或者范围查询：gap lock / next key lock
行锁和gap锁之间最大的区别是：
- 行锁针对确定的记录
- 间隙锁是两个确定记录之间的范围； next key lock则是除了间隙还包括确定的记录
3. 实例演示
看上面的两个说明，自然就想在实际的case中操刀分析一下，不同的sql会产生什么样的锁效果
- 针对表中一条确定的记录加X锁，是只有行锁嘛？
- 针对表中多条确定的记录加X锁，又会怎样？
- 针对表中一条不存在的记录加X锁，会有锁产生吗？如果是gap锁，那区间怎么定？
- 针对范围加X锁，产生的gap锁范围怎么确定呢？
在分析上面几种case之前，我们得先有一个概念，锁是针对索引而言的，这一点非常非常重要
其次不同的索引，我们需要分别进行测试（其实就是唯一索引与普通索引）
3.1 表准备
接下来针对上面的四种场景，设计我们的测试用例，首先我们准备三张表
- 无索引表 TN
- 唯一索引表 TU
- 普通索引表 TI
对应的表结构和初始化数据如下
CREATE TABLE `tn` (
`id` int(11) unsigned NOT NULL,
`uid` int(11) unsigned NOT NULL
) ENGINE=InnoDB;
CREATE TABLE `tu` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`uid` int(11) unsigned NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `u_uid` (`uid`)
) ENGINE=InnoDB;
CREATE TABLE `ti` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`uid` int(11) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `u_uid` (`uid`)
) ENGINE=InnoDB;
INSERT INTO `tn` (`id`, `uid`) VALUES (1, 10), (5, 20), (10, 30);
INSERT INTO `tu` (`id`, `uid`) VALUES (1, 10), (5, 20), (10, 30);
INSERT INTO `ti` (`id`, `uid`) VALUES (1, 10), (5, 20), (10, 30);
3.2 精确匹配
即我们的sql可以精确命中某条记录时，锁的情况如下：
请注意上面的结论，无索引时锁全表好理解，但是普通索引的TI表，居然还有一个[10, 30)的gap锁就有点超乎我们的想象了；
接下来我们验证一下
上图基本流程如下：
从上面的实测也可以看出，普通索引下添加x锁，居然会加一个gap锁，而且这个gap区间是前一个记录（并包含它），到下一个记录
如 uid = 20， 前后两个记录为(1, 10), (10, 30)
- gap lock: 范围为 [10, 30)
- 因此无法插入uid=[10,30)
- 注意，uid=10上有gap锁只是不能插入记录，但是加X锁是没有问题的（有兴趣的可以测试一下）
3.3 精确查询未匹配
当我们锁的记录不存在时，锁情况如下：
实测case如下(TN省略，锁全表的没啥测试必要性)
基本流程就不画图了，上面图中已经有文字描述了
从上面的测试也可以看出，uid=30没有被锁住，这里只在uid=(20, 30)这一区间添加了gap锁
唯一索引与普通索引表现一致，会阻塞insert的插入意向锁（后面说这个东西）
3.4 范围查询
当我们锁一段区间时，锁的情况如下：
简单来说，范围查询时，添加next key lock，根据我们的查询条件，找到最左边和最右边的记录区间
如 uid > 15 and uid < 25，找到的记录是(1, 10), (10, 30)
- gap锁为(10, 30)
- next key lock会为右边添加行锁，即uid=30加X锁
- 因此针对uid=30记录加锁会被阻塞（但是针对uid=28,29加x锁则不会被阻塞，插入会，有兴趣的小伙伴可以实测一下）
说明：范围加x锁时，可能锁住不在这个区间的记录，一不小心可能导致死锁哦
3.5 小结
在RR隔离级别中，我们一般认为可以产生锁的语句为:
- SELECT ... FOR UPDATE: X锁
- SELECT ... LOCK IN SHARE MODE: S锁
- update/delete: X锁
| 普通索引 | 精确匹配，且命中 | 行锁 + gap lock (上一个记录和下个记录区间，左闭右开，左边记录非行锁) | 普通索引 | 精确匹配，未命中 | gap lock | | 普通索引 | 范围查询 | next key lock |
4. 锁冲突
上面介绍了不同场景下会产生什么样的锁，但是看完之后会有一个疑问，针对行锁其他会话竞争的时候，可以按照X/S锁的规则来，但是这个GAP LOCK貌似只针对insert有效，insert除了加X锁之外是不是还有其他的特殊逻辑？
4.1 插入意向锁
插入意向锁其实是一种特殊的 gap lock，但是它不会阻塞其他锁。假设存在值为 4 和 7 的索引记录，尝试插入值 5 和 6 的两个事务在获取插入行上的排它锁之前使用插入意向锁锁定间隙，即在（4，7）上加 gap lock，但是这两个事务不会互相冲突等待；但是如果这个区间存在gap lock，则会被阻塞；如果多个事务插入相同数据导致唯一冲突，则在重复的索引记录上加读锁
简单来说，它的属性为：
- 它不会阻塞其他任何锁；
- 它本身仅会被 gap lock 阻塞
其次一个重要知识点：
-
通常insert语句，加的是行锁，排它锁
-
在insert之前，先通过插入意向锁，判断是否可以插入（仅会被gap lock阻塞）
-
当插入唯一冲突时，在重复索引上添加读锁
-
原因如下：
-
事务1 插入成功未提交，获取了排它锁，但是事务1最终可能会回滚，所以其他重复插入事务不应该直接失败，这个时候他们改为申请读锁（疑问点：为什么要改成读锁呢？）
4.2 锁冲突矩阵
简单版矩阵
当我们将gap lock(间隙锁), next key lock(next-key锁), Insert Intention lock(插入意向锁)也加入矩阵时，就会复杂很多了
一次并发插入死锁带来的“教训”，我才清楚这些MySQL锁知识
说明：
- not gap: 行锁
- gap: gap lock
- next-key: gap + 行锁
小结：
针对上面的矩阵，理解下面几个原则即可推导上面矩阵
- gap lock只会与插入意向锁冲突
- X行锁会与行锁冲突
- next key lock: 行锁 + gap锁 锁区间内，插入冲突； 行锁的X锁冲突
二、并发插入死锁分析
上面属于基本知识点，接下来我们看一个实际导致死锁的case
- 并发插入相同记录导致死锁
0. 表准备
创建一个最简单最基础的表，用于演示
CREATE TABLE `t` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
INSERT INTO `t` (`id`) VALUES (1);
1. 事务回滚的死锁问题
场景复现:
step1：
-- session1:
begin; insert into t values (2);
-- session2:
begin; insert into t values (2);
-- 阻塞
-- session3:
begin; insert into t values (2);
-- 阻塞
step2：
-- session1:
rollback;
原因分析：
死锁日志查看
SHOW ENGINE INNODB STATUS;
step1：
- session1: 插入(id=2)，会添加一个X + Next Lock锁
- session2/3: 插入(id=2)，插入意向锁被阻塞，改为持有S + Next Lock锁
step2：
- session1: 回滚，释放X锁
- session2/3: 竞争X锁，只有对方释放S锁，才能竞争成功；相互等待，导致死锁
2. delete导致死锁问题
和前面操作基本一致，只是第一个会话是删除记录
step1：
-- session1:
begin; delete from t where id=1;
-- session2:
begin; insert into t values (1);
-- 阻塞
-- session3:
begin; insert into t values (1);
-- 阻塞
step2：
-- session1:
commit;
原因分析和前面基本一致
3. insert加锁逻辑
insert中对唯一索引的加锁逻辑
- 先做UK冲突检测，如果存在目标行，先对目标行加S Next Key Lock（该记录在等待期间被其他事务删除，此锁被同时删除）
- 如果1成功，对对应行加X + 插入意向锁
- 如果2成功，插入记录，并对记录加X + 行锁（有可能是隐式锁）
根据上面这个的逻辑，那么就会有一个有意思的死锁场景
step1：
-- session1
begin; delete from t where id = 1;
-- session2
begin; delete from t where id = 1;
step2：
-- session1
insert into t values(1)
对应的死锁日志
关于这个场景详情博文可以参考：记录一次Mysql死锁排查过程
4. 怎么避免死锁呢?
- 将大事务拆成小事务
- 添加合理的索引，走索引避免为每一行加锁，降低死锁的概率
- 避免业务上的循环等待（如加分布式锁之类的）
- 降低事务隔离级别（如RR -> RC 当然不建议这么干）
- 并发插入时使用replace/on duplicate也可以避免死锁
三、总结
尽信书则不如，以上内容，纯属一家之言，因个人能力有限，难免有疏漏和错误之处，如发现bug或者有更好的建议，欢迎批评指正，不吝感激。
作者：一灰灰
链接：https://juejin.cn/post/6927197371227095047
来源：掘金
网友评论