浅谈MySQL next-key lock 加锁范围

吾爱主题阅读：139 2024-04-02 08:03:05 评论：0

前言

某天，突然被问到 mysql 的 next-key lock，我瞬间的反应就是：

这都是啥啥啥？？？

这一个截图我啥也看不出来呀？

仔细一看，好像似曾相识，这不是《mysql 45 讲》里面的内容么？

什么是 next-key lock

a next-key lock is a combination of a record lock on the index record and a gap lock on the gap before the index record.

官网的解释大概意思就是：锁是索引记录上的记录锁和索引记录之前的间隙上的间隙锁的组合。

先给自己来一串小问号？？？

在主键、唯一索引、普通索引以及普通字段上加锁，是锁住了哪些索引？
不同的查询条件，分别锁住了哪些范围的数据？
for share 和 for update 等值查询和范围查询的锁范围？
当查询的等值不存在时，锁范围是什么？
当查询条件分别是主键、唯一索引、普通索引时有什么区别？

既然啥都不懂，那只好从头开始操作实践一把了！

先看看看《mysql 45 讲》中丁奇老师的结论：

看了这结论，应该可以解答一大部分问题，不过有一句非常非常重点的话需要关注：mysql 后面的版本可能会改变加锁策略，所以这个规则只限于截止到现在的最新版本，即 5.x 系列<=5.7.24，8.0 系列 <=8.0.13

所以，以上的规则，对现在的版本并不一定适用，下面我以 mysql 8.0.25 版本为例，进行多角度验证 next-key lock 加锁范围。

环境准备

mysql 版本：8.0.25

隔离级别：可重复读（rr）

存储引擎：innodb

1 2	`mysql>` `select` `@@` `global` `.transaction_isolation,@@transaction_isolation\g` `mysql> show` `create` `table` `t\g`

如何使用 docker 安装 mysql，可以参考另一篇文章《使用 docker 安装并连接 mysql》

主键索引

首先来验证主键索引的 next-key lock 的范围

此时数据库的数据如图所示，对主键索引来说此时数据间隙如下：

主键等值查询 —— 数据存在

1	`mysql>` `begin` `;` `select` `*` `from` `t` `where` `id = 10` `for` `update` `;`

这条 sql，对 id = 10 进行加锁，可以先思考一下加了什么锁？锁住了什么数据？

可以通过 data_locks 查看锁信息，sql 如下：

1 2	`# mysql>` `select` `` `from` `performance_schema.data_locks;` `mysql>` `select` `` `from` `performance_schema.data_locks\g`

具体字段含义可以参考

结果主要包含引擎、库、表等信息，咱们需要重点关注以下几个字段：

index_name：锁定索引的名称
lock_type：锁的类型，对于 innodb，允许的值为 record 行级锁和 table 表级锁。
lock_mode：锁的类型：s, x, is, ix, and gap locks
lock_data：锁关联的数据，对于 innodb，当 lock_type 是 record（行锁），则显示值。当锁在主键索引上时，则值是锁定记录的主键值。当锁是在辅助索引上时，则显示辅助索引的值，并附加上主键值。

结果很明显，这里是对表添加了一个 ix 锁并对主键索引 id = 10 的记录，添加了一个 x,rec_not_gap 锁，表示只锁定了记录。

同样 for share 是对表添加了一个 is 锁并对主键索引 id = 10 的记录，添加了一个 s 锁。

可以得出结论：

对主键等值加锁，且值存在时，会对表添加意向锁，同时会对主键索引添加行锁。

主键等值查询 —— 数据不存在

1	`mysql>` `select` `*` `from` `t` `where` `id = 11` `for` `update` `;`

如果是数据不存在的时候，会加什么锁呢？锁的范围又是什么？

在验证之前，分析一下数据的间隙。

id = 11 是肯定不存在的。但是加了 for update，这时需要加 next-key lock，id = 11 所属区间为 (10,15] 的前开后闭区间；
因为是等值查询，不需要锁 id = 15 那条记录，next-key lock 会退化为间隙锁；
最终区间为 (10,15) 的前开后开区间。

使用 data_locks 分析一下锁信息：

看下锁的信息 x,gap 表示加了间隙锁，其中 lock_data = 15，表示锁的是主键索引 id = 15 之前的间隙。

此时在另一个 session 执行 sql，答案显而易见，是 id = 12 不可以插入，而 id = 15 是可以更新的。

可以得出结论，在数据不存在时，主键等值查询，会锁住该主键查询条件所在的间隙。

主键范围查询（重点）

1	`mysql>` `begin` `;` `select` `*` `from` `t` `where` `id >= 10` `and` `id < 11` `for` `update` `;`

根据《mysql 45 讲》分析得出下面结果：

id >= 10 定位到 10 所在的区间 (10,+∞)；
因为是 >= 存在等值判断，所以需要包含 10 这个值，变为 [10,+∞) 前闭后闭区间；
id < 11 限定后续范围，则根据 11 判断下一个区间为 15 的前开后闭区间；
结合起来则是 [10,15]。（不完全正确）

先看下 data_locks

可以看到除了表锁之外，还有 id = 10 的行锁（x,rec_not_gap）以及主键索引 id = 15 之前的间隙锁（x,gap）。

所以实际上 id = 15 是可以进行更新的。也就是说前开后闭区间出现了问题，个人认为应该是 id < 11 这个条件判断，导致不需要进行了锁 15 这个行锁。

结果验证也是正确的，id = 12 插入阻塞，id = 15 更新成功。

当范围的右侧是包含等值查询呢？

1	`mysql>` `begin` `;` `select` `*` `from` `t` `where` `id > 10` `and` `id <= 15` `for` `update` `;`

来分析一下这个 sql：

id > 10 定位到 10 所在的区间 (10,+∞)；id <= 15 定位是 (-∞, 15]；结合起来则是 (10,15]。

同样先看一下 data_locks

可以看出只添加了一个主键索引 id = 15 的 x 锁。

验证下 id = 15 是否可以更新？再验证 id = 16 是否可以插入？

事实证明是没有问题的！

当然，这里有小伙伴会说，在《mysql 45 讲》里面说这里有一个 bug，会锁住下一个 next-key。

事实证明，这个 bug 已经被修复了。修复版本为 mysql 8.0.18。但是并没有完全修复！！！

参考链接地址：

搜索关键字：bug #29508068)

咱们可以分别用 8.0.17 进行复现一下：

在 8.0.17 中 id <= 15 会将 id = 20 这条数据也锁着，而在 8.0.25 版本中则不会。所以这个 bug 是被修复了的。

再来看下是前开后闭还是前开后开的问题，严谨一下，使用 8.0.17 和 8.0.18 做比较。

现在我估计大概率是在 8.0.18 版本修复 bug #29508068 的时候，把这个前开后闭给优化成了前开后开了。

对比 data_locks 数据：

注意红色下划线部分，在 8.0.17 版本中 id < 17 时 lock_mode 是 x，而在 8.0.25 版本中则是 x,gap。

总结

本文主要通过实际操作，对主键加锁时的 next-key lock 范围进行了验证，并查阅资料，对比版本得出不同的结论。

结论一：

加锁时，会先给表添加意向锁，ix 或 is；
加锁是如果是多个范围，是分开加了多个锁，每个范围都有锁；（这个可以实践下 id < 20 的情况）
主键等值查询，数据存在时，会对该主键索引的值加行锁 x,rec_not_gap；
主键等值查询，数据不存在时，会对查询条件主键值所在的间隙添加间隙锁 x,gap；
主键等值查询，范围查询时情况则比较复杂：
- 8.0.17 版本是前开后闭，而 8.0.18 版本及以后，进行了优化，主键时判断不等，不会锁住后闭的区间。
- 临界 <= 查询时，8.0.17 会锁住下一个 next-key 的前开后闭区间，而 8.0.18 及以后版本，修复了这个 bug。