图文实例解析，InnoDB 存储引擎中行锁的三种算法

水深无声 2022-09-03 15:20 7阅读 0赞

前文提到，对于 InnoDB 来说，随时都可以加锁，但是并非随时都可以解锁。具体来说，InnoDB 采用的是**两阶段锁定协议（two-phase locking protocol）**：即在事务执行过程中，随时都可以执行加锁操作，但是**只有在事务执行 COMMIT 或者 ROLLBACK 的时候才会释放锁**，并且所有的锁是在同一时刻被释放。

并且，行级锁只在存储引擎层实现，而对于 InnoDB 存储引擎来说，行级锁又分三种，或者说有三种行级锁算法：

*  Record Lock：记录锁
 *  Gap Lock：间隙锁
 *  Next-Key Lock：临键锁

下面，我们来详细解释下这三种行锁算法。

## Record Lock 记录锁 ##

顾名思义，记录锁就是为**某行记录**加锁，事实上，它封锁的是该行的**索引记录**。如果表在建立的时候没有设置任何一个索引，那么这时 InnoDB 存储引擎会使用 “**隐式的主键**” 来进行锁定。

所谓隐式的主键就是指：如果在建表的时候没有指定主键，InnoDB 存储引擎会将第一列非空的列作为主键；如果没有的话会自动生成一列为 6 字节的主键。

那么，既然 Record Lock 是基于索引的，那如果我们的 SQL 语句中的条件导致索引失效（比如使用 `or`） 或者说条件根本就不涉及索引或者主键，行级锁就将退化为表锁。

### Record Lock 示例 ###

先来举个对索引字段进行查询的例子，有数据库如下，id 是主键索引：

CREATE TABLE `test` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `username` varchar(255) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

初始数据是这样的：

![3f0ce34bb3a5e74ce760591fad4634f0.png][]

新建两个事务，**先执行事务 T1 的前两行，也就是不要执行 commit**：

![3e16925ee97a7f236dc5971f7d4c19f9.png][]

由于没有执行 commit，所以这个时候事务 T1 没有释放锁，并且锁住了 id = 1 的记录行，此时再来执行事务 2 申请 id = 2 的记录行：

![1e4864dc1e79830a8ea5b4052b31a8bb.png][]

可以看见，由于锁住的是不同的记录行，所以两个记录锁并没有相互排斥，来看一下现在表中的数据，由于事务 1 还没有 commit，所以应该是只有 id = 2 的 username 被修改了：

![7396bb428e1be9328a1bc1ca79024996.png][]

nice，果然。再执行下事务 1 的 commit，id = 1 的 username 也就被修改过来啦。

### 行锁退化为表锁示例 ###

再来看下没有使用索引的例子：

同样的，新建两个事务，**先执行事务 T1 的前两行，也就是不要执行 commit**。我们试图使用 `select ... for update` 给 username = "user\_three" 的记录行加上记录锁，但是由于 username 并非主键也并非索引，所以实际上这里事务 T1 锁住的是整张表：

![f334cf445e34412c406c4ce46a50935a.png][]

由于没有执行 commit，所以这个时候事务 T1 没有释放锁，并且锁住了整张表。此时再来执行事务 2 试图申请 id = 5 的记录锁，你会发现事务 T2 会卡住，最后超时关闭事务：

![bd12f22daf231ac163894c972381fef6.png][]

### 两条不同记录拥有相同的索引，会发生锁冲突吗？ ###

这个问题的答案应该很简单吧，上面我们强调过，行锁锁住的是索引，而不是一条记录（只不过我们平常这么说锁住了哪条记录，比较好理解罢了）。所以**如果两个事务分别操作的两条不同记录拥有相同的索引，某个事务会因为行锁被另一个事务占用而发生等待**。

## Gap Lock 间隙锁 ##

这里我先简单提一嘴，下文会详细解释：不同于 Record Lock 是基于唯一索引的，Gap Lock 和 Next-Key Lock 都是基于**非唯一索引**的。

并且，不同于 Record Lock 锁定的是某一个索引记录，Gap Lock 和 Next-Key Lock 锁定的都是**一段范围内**的索引记录：

select * from test where id between 1 and 10 for update;

对于上述 SQL 语句，所有在`（1，10）`区间内（**左开右开**）的记录行都会被 Gap Lock 锁住，所有 id 为 2、3、4、5、6、7、8、9 的数据行的插入会被阻塞，但是 1 **和 10 两条被操作的索引记录并不会被锁住**。

注意！这里指的是锁住所有的（1，10）区间内的 id，也就是说即使某个 id 目前并不在我们的表中比如 id = 6 ，如果你想插入一条 id = 6 的新纪录，那对不起，不行。

## Next-Key Lock 临键锁 ##

Next-Key Lock 是结合了 Gap Lock 和 Record Lock 的一种锁定算法，**其主要目的是为了解决幻读问题**。

例如一个索引有 10，11，13 和 20 这四个值，分别对这个 4 个索引进行加锁操作，那么这四个操作分别对应的 Next-Key Lock 锁住的区间是：

*  `(-∞, 10]`
 *  `(10, 11]`
 *  `(11, 13]`
 *  `(13, 20]`
 *  `(20, +∞]`

细心的同学应该已经注意到了，和 Gap Lock 的不同之处就在于，Next-Key Lock 锁定的区间是**左开右闭**的，也就是说它是**包含当前被操作的索引记录**的。

在 InnoDB 默认的隔离级别 REPEATABLE-READ 下，行锁默认使用的算法就是 Next-Key Lock。但是，**如果操作的索引是唯一索引或主键，InnoDB 会对 Next-Key Lock 进行优化，将其降级为 Record Lock**，即仅锁住索引本身，而不是范围。

由于**主键也是一种唯一索引**，所以我们可以这么说：**Record Lock 是基于唯一索引的，而 Next-Key Lock 是基于非唯一索引的**。

需要注意的，**当操作的索引为非唯一索引时，InnoDB 会先用 Record Lock 锁住对应的唯一索引，再用 Next-Key Lock 和 Gap Lock 对这个非唯一索引进行处理**，而不仅仅是锁住这个非唯一索引。具体地我们举个例子来看下。

### Next-Key Lock 示例 ###

假设我们为上面 test 表中新增一个字段，并设置为非唯一索引：

CREATE TABLE `test` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `username` varchar(255) DEFAULT NULL,
      `class` int(11) NOT NULL,
      PRIMARY KEY (`id`),
      KEY `index_class` (`class`) USING BTREE COMMENT '非唯一索引'
    ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

插入一些数据：

![17ce487058a39bc5c587e932c34afd0b.png][]

开启一个事务 1 执行如下的操作语句：

select * from test where class = 3 for update;

![43b1d87d9b7e5919a4e981b111c216f3.png][]

在这种情况下，InnoDB 事实上会加上三种行锁（`select * ... from update` 加的是行级写锁即 X 锁）：

1）给主键索引 id = 105 加上 Record Lock

2）对于非唯一索引 class = 3，其加上的是 Next-Key Lock，锁定的范围是 `(1，3]`

3）另外，特别需要注意的是，InnoDB 存储引擎还会对非唯一索引 class 的**下一个键值**加上 Gap Lock（表中  class = 3 的下个键值是 6），所以还有一个 class 索引范围为 `(3，6)` 的间隙锁

总结下 2）和 3），对于这条 SQL 语句，InnoDB 存储引擎锁定地 class 索引范围是 `(1, 6)`

下面我们用实践来验证理论，再开启一个事务 2，执行下述的语句：

![88ee8c89dfa6a871c1528aa51f356f97.png][]

不出所料，由于在事务 1 中执行的 SQL 语句已经对主键索引中列 a=105 的记录加上了 X 锁，所以此处再去获取 这个记录的 X 锁会被阻塞住。

再用一个事务来执行下述 SQL 语句：

![b9bfb9421046eef977ea1d5a2c6a0d7b.png][]

主键插入 104 没有任何问题，但是插入的 class 索引值 2 在被锁定的范围 (1，6) 中，因此执行同样会被阻塞住。

经过上面的分析，大家一定能够知道下面的 SQL 语句是可以正常执行的：

![a520833e64a524bb0e4a04d34b888999.png][]

### Attention ###

需要注意的是，Next-Key Lock 降级为 Record Lock 仅存在于操作所有的唯一索引列的情况。**若唯一索引由多个列组成，而操作的仅是多个唯一索引列中的其中一个，那么 InnoDB 存储引擎依然使用 Next-Key Lock 进行锁定**。

推荐好文

[强大，10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程！][10k_ SpringBoot]

[分享一套基于SpringBoot和Vue的企业级中后台开源项目，代码很规范！][SpringBoot_Vue]

[能挣钱的，开源 SpringBoot 商城系统，功能超全，超漂亮][SpringBoot]![12a700e0d55020f8f3692b06fc7f909e.png][]

[3f0ce34bb3a5e74ce760591fad4634f0.png]: /images/20220829/b815c92cdc0441f0b442c377aa3d7433.png
[3e16925ee97a7f236dc5971f7d4c19f9.png]: /images/20220829/731a422e0d374225a67a96af592afa20.png
[1e4864dc1e79830a8ea5b4052b31a8bb.png]: /images/20220829/704fd209759140059ad0d94065f72296.png
[7396bb428e1be9328a1bc1ca79024996.png]: /images/20220829/352e6039ba914349b30e45ecf031b942.png
[f334cf445e34412c406c4ce46a50935a.png]: /images/20220829/b035355a0b644e6b8e33b3a8fcd4ca6c.png
[bd12f22daf231ac163894c972381fef6.png]: /images/20220829/d34d9ece13654cc3b5acf1d3e3ab7c93.png
[17ce487058a39bc5c587e932c34afd0b.png]: /images/20220829/3510fc1c98c0494aa3d002e7d81fc3a6.png
[43b1d87d9b7e5919a4e981b111c216f3.png]: /images/20220829/b87cce982e004674ba2d90e4086537a1.png
[88ee8c89dfa6a871c1528aa51f356f97.png]: /images/20220829/1c5f5a4369dc45d4a864759b6cdd9187.png
[b9bfb9421046eef977ea1d5a2c6a0d7b.png]: /images/20220829/d86aaae2c5564735927140dba01b2252.png
[a520833e64a524bb0e4a04d34b888999.png]: /images/20220829/f746d3a27ff74fa5914d925128017c91.png
[10k_ SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ%3D%3D&chksm=ebd5c411dca24d07446a4f22772cd12d2cc1143b62eb922a14500ae981cd57fb850ef74ca257&idx=2&mid=2247498557&scene=21&sn=84902d7030e174e152615d8fae3755cc#wechat_redirect
[SpringBoot_Vue]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799be6cb0e12f0b58479f8b031bc5ae79efdca1880ff9b19f0a107c3a88c37b9596dc73203&idx=2&mid=2247497288&scene=21&sn=65d7111a19e920df1e9416959594b2f4#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU2MTI4MjI0MQ%3D%3D&chksm=fc799a9ccb0e138a64a2671f31b8d4be1b3c061a288f7b0d1d4af02a60c45a72231446b91e00&idx=2&mid=2247497522&scene=21&sn=c5b4e596be4ac7d7f293e7e2f0ea0769#wechat_redirect
[12a700e0d55020f8f3692b06fc7f909e.png]: /images/20220829/99b15b0831de4099a7f67107f3043d11.png