MySQL相关（八）- innodb行级锁深入剖析

前言

上一篇章我们讲的是 innodb 锁的基本类型及使用，相信用过的小伙伴很快就能上手，但是我们学习一个东西，要知其然知其所以然。

我们来思考两个问题，首先，锁的作用是什么？它跟 Java 里面的锁是一样的，是为了解决资源竞争的问题，Java 里面的资源是对象，数据库的资源就是数据表或者数据行。

所以锁是用来解决事务对数据的并发访问的问题的。

那么，锁到底锁住了什么呢？

当一个事务锁住了一行数据的时候，其他的事务不能操作这一行数据，那它到底是锁住了这一行数据，还是锁住了这一个字段，还是锁住了别的什么东西呢？

老规矩，先上飞机票：

1. MySQL相关（一）- 一条查询语句是如何执行的
2. MySQL相关（二）- 一条更新语句是如何执行的
3. MySQL相关（番外篇）- innodb 逻辑存储结构；
4. MySQL相关（三）- 索引数据模型推演及 B+Tree 的详细介绍；
5. MySQL相关（四）- 性能优化关键点索引
6. MySQL相关（五）- 事务特性及隔离级别的详细介绍
7. MySQL相关（六）- 事务隔离级别的实现方案（MVCC）
8. MySQL相关（七）- innodb 锁的介绍及使用

前面提到的脑图如下，想要完整高清图片可以到微信我的公众号下【6曦轩】下回复 MySQL 脑图获取：

在这里插入图片描述

正文

行锁的原理

没有索引的表（假设锁住记录）

首先我们有三张表，一张没有索引的 t1，一张有主键索引的 t2，一张有唯一索引的t3。

我们先假设 InnoDB 的锁锁住了是一行数据或者一条记录。

我们先来看一下 t1 的表结构，它有两个字段，int 类型的 id 和 varchar 类型的 name。

里面有 4 条数据，1、2、3、4。

Transaction 1	Transaction 2
begin;
SELECT * FROM t1 WHERE id =1 FOR UPDATE;
-	select * from t1 where id=3 for update;//blocked
-	INSERT INTO t1 (id, name) VALUES (5, '5'); //blocked

现在我们在两个会话里面手动开启两个事务。

在第一个事务里面，我们通过 where id =1 锁住第一行数据。

在第二个事务里面，我们尝试给 id=3 的这一行数据加锁，大家觉得能成功吗？

很遗憾，我们看到红灯亮起，这个加锁的操作被阻塞了。这就有点奇怪了，第一个事务锁住了 id=1 的这行数据，为什么我不能操作 id=3 的数据呢？

我们再来操作一条不存在的数据，插入 id=5。它也被阻塞了。实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，InnoDB 的锁锁住的应该不是 Record。

那为什么在没有索引或者没有用到索引的情况下，会锁住整张表？这个问题我们先留在这里。

我们继续看第二个演示。

有主键索引的表

我们看一下 t2 的表结构。字段是一样的，不同的地方是 id 上创建了一个主键索引。

里面的数据是 1、4、7、10。

Transaction 1	Transaction 2
begin;
select * from t2 where id=1 for update;
-	select * from t2 where id=1 for update; //blocked
-	select * from t2 where id=4 for update; // OK

第一种情况，使用相同的 id 值去加锁，冲突；使用不同的 id 加锁，可以加锁成功。那么，既然不是锁定一行数据，有没有可能是锁住了 id 的这个字段呢？

唯一索引（假设锁住字段）

我们看一下 t3 的表结构。字段还是一样的， id 上创建了一个主键索引，name 上创建了一个唯一索引。里面的数据是 1、4、7、10。

Transaction 1	Transaction 2
begin;
select * from t3 where name= '4' for update;
-	select * from t3 where name = '4' for update;// blocked
-	select * from t3 where id = 4 for update; //blocked

在第一个事务里面，我们通过 name 字段去锁定值是 4 的这行数据。

在第二个事务里面，尝试获取一样的排它锁，肯定是失败的，这个不用怀疑。

在这里我们怀疑 InnoDB 锁住的是字段，所以这次我换一个字段，用 id=4 去给这行数据加锁，大家觉得能成功吗？

很遗憾，又被阻塞了，说明锁住的是字段的这个推测也是错的，否则就不会出现第一个事务锁住了 name，第二个字段锁住 id 失败的情况。

既然锁住的不是 record，也不是 column，InnoDB 里面锁住的到底是什么呢？在这三个案例里面，我们要去分析一下他们的差异在哪里，也就是这三张表的结构，是什么区别导致了加锁的行为的差异？其实答案就是索引。InnoDB 的行锁，就是通过锁住索引来实现的。

那索引又是个什么东西？为什么它可以被锁住？在前面的文章中我们已经分析过了（可回头复习或观看）。

那么我们还有两个问题没有解决：

1. 为什么表里面没有索引的时候，锁住一行数据会导致锁表？或者说，如果锁住的是索引，一张表没有索引怎么办？所以，一张表有没有可能没有索引？

1）如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
2）如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引。
3）如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。

所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。

2. 为什么通过唯一索引给数据行加锁，主键索引也会被锁住？

大家还记得在 InnoDB 里面，当我们使用辅助索引的时候，它是怎么检索数据的吗？
辅助索引的叶子节点存储的是什么内容？

在辅助索引里面，索引存储的是二级索引和主键的值。比如 name=4，存储的是 name 的索引和主键 id 的值 4。

而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。

在这里插入图片描述

现在我们已经搞清楚 4 个锁的基本类型和锁的原理了，在官网上，还有 3 种锁，我们把它理解为锁的算法。我们也来看下 InnoDB 在什么时候分别锁住什么范围。

锁的算法

我们先来看一下我们测试用的表，t2，这张表有一个主键索引。

我们插入了 4 行数据，主键值分别是 1、4、7、10。

为了让大家真正理解这三种行锁算法的区别，我们需要了解一下三种范围的概念。

因为我们用主键索引加锁，我们这里的划分标准就是主键索引的值。

在这里插入图片描述

这些数据库里面存在的主键值，我们把它叫做 Record，记录，那么这里我们就有 4 个 Record。

根据主键，这些存在的 Record 隔开的数据不存在的区间，我们把它叫做 Gap，间隙，它是一个左开右开的区间。

最后一个，间隙（Gap）连同它左边的记录（Record），我们把它叫做临键的区间，它是一个左开右闭的区间。

t2 的主键索引，它是整型的，可以排序，所以才有这种区间。如果我的主键索引不是整形，是字符怎么办呢？字符可以排序吗？ 用 ASCII 码来排序。

我们已经弄清楚了三个范围的概念，下面我们就来看一下在不同的范围下，行锁是怎么表现的。

记录锁

第一种情况，当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录的时候，这个时候使用的就是记录锁。

比如 where id = 1 4 7 10 。

这个演示我们在前面已经看过了。我们使用不同的 key 去加锁，不会冲突，它只锁住这个 record。

间隙锁

第二种情况，当我们查询的记录不存在，没有命中任何一个 record，无论是用等值

查询还是范围查询的时候，它使用的都是间隙锁。

举个例子，where id >4 and id <7，where id = 6。

Transaction 1	Transaction 2
begin;
-	INSERT INTO t2 (id, name) VALUES (5, '5'); // BLOCKED
-	INSERT INTO t2 (id, name) VALUES (6, '6'); // BLOCKED
-	select * from t2 where id =6 for update; // OK
select * from t2 where id >20 for update;
-	INSERT INTO t2 (id, name) VALUES (11, '11'); // BLOCKED

重复一遍，当查询的记录不存在的时候，使用间隙锁。

注意，间隙锁主要是阻塞插入 insert。相同的间隙锁之间不冲突。

Gap Lock 只在 RR 中存在。如果要关闭间隙锁，就是把事务隔离级别设置成 RC，并且把 innodb_locks_unsafe_for_binlog 设置为 ON。

这种情况下除了外键约束和唯一性检查会加间隙锁，其他情况都不会用间隙锁。

临键锁

第三种情况，当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap 间隙，在这种情况下我们使用的就是临键锁，它是 MySQL 里面默认的行锁算法，相当于记录锁加上间隙锁。

其他两种退化的情况：

1. 唯一性索引，等值查询匹配到一条记录的时候，退化成记录锁。
2. 没有匹配到任何记录的时候，退化成间隙锁。

比如我们使用>5 <9， 它包含了记录不存在的区间，也包含了一个 Record 7。

Transaction 1	Transaction 2
begin;
select * from t2 where id >5 and id < 9 for update;
-	begin;
-	select * from t2 where id =4 for update; // OK
-	INSERT INTO t2 (id, name) VALUES (6, '6'); // BLOCKED
-	INSERT INTO t2 (id, name) VALUES (8, '8'); // BLOCKED
-	select * from t2 where id =10 for update; // BLOCKED

临键锁，锁住最后一个 key 的下一个左开右闭的区间。

select * from t2    where id >5 and id <=7 for update;  --  锁住(4,7]和(7,10]
select * from t2    where id >8 and id <=10 for update; --  锁住 (7,10]，(10,+∞)

为什么要锁住下一个左开右闭的区间？——就是为了解决幻读的问题。

小结：隔离级别的实现

所以，我们再回过头来看下这张图片，为什么 InnoDB 的 RR 级别能够解决幻读的问题，就是用临键锁实现的。

我们再回过头来看下这张图片，这个就是 MySQL InnoDB 里面事务隔离级别的实现。

在这里插入图片描述

最后我们来总结一下四个事务隔离级别的实现：

Read Uncommited

RU 隔离级别：不加锁。

Serializable

Serializable 所有的 select 语句都会被隐式的转化为 select ... in share mode，会和 update、delete 互斥。

这两个很好理解，主要是 RR 和 RC 的区别？

Repeatable Read

RR隔离级别下，普通的 select 使用快照读(snapshot read)，底层使用 MVCC 来实现。

加锁的 select(select ... in share mode / select ... for update) 以及更新操作 update, delete 等语句使用当前读（current read），底层使用记录锁、或者间隙锁、临键锁。

Read Commited

RC 隔离级别下，普通的 select 都是快照读，使用 MVCC 实现。

加锁的 select 都使用记录锁，因为没有 Gap Lock。

除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会使用间隙锁封锁区间。

所以 RC 会出现幻读的问题。

事务隔离级别怎么选？

https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html

RU 和 Serializable 肯定不能用。为什么有些公司要用 RC，或者说网上有些文章推荐有 RC？

RC 和 RR 主要有几个区别：

1. RR 的间隙锁会导致锁定范围的扩大。

2. 条件列未使用到索引，RR 锁表，RC 锁行。

3. RC 的“半一致性”（semi-consistent）读可以增加 update 操作的并发性。

在RC 中，一个 update 语句，如果读到一行已经加锁的记录，此时 InnoDB 返回记录最近提交的版本，由 MySQL 上层判断此版本是否满足 update 的 where 条件。若满足(需要更新)，则 MySQL 会重新发起一次读操作，此时会读取行的最新版本(并加锁)。

实际上，如果能够正确地使用锁（避免不使用索引去枷锁），只锁定需要的数据，用默认的 RR 级别就可以了。

By the way

有问题？可以给我留言或私聊
有收获？那就顺手点个赞呗~

当然，也可以到我的公众号下「6曦轩」，

回复“学习”，即可领取一份
【Java工程师进阶架构师的视频教程】~

回复“面试”，可以获得：
【本人呕心沥血整理的 Java 面试题】

回复“MySQL脑图”，可以获得
【MySQL 知识点梳理高清脑图】

由于我咧，科班出身的程序员，php，Android以及硬件方面都做过，不过最后还是选择专注于做 Java，所以有啥问题可以到公众号提问讨论（技术情感倾诉都可以哈哈哈），看到的话会尽快回复，希望可以跟大家共同学习进步，关于服务端架构，Java 核心知识解析，职业生涯，面试总结等文章会不定期坚持推送输出，欢迎大家关注~~~

在这里插入图片描述