MySQL 学习(二)：一文了解MySQL InnoDB 的好几种锁

本文主要是介绍MySQL 学习(二)：一文了解MySQL InnoDB 的好几种锁，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

说明

本篇博文我将对 MySQL 官方文档的 InnoDB Locking 章节进行翻译学习，通过文档来了解 MySQL 的 InnoDB 引擎的锁的概念，文档基于 MySQL8 版本。示例代码均使用默认的事务隔离级别。

通过本篇博文，我们应该了解 InnoDB 有哪些锁，不同类型锁的概念及其作用。

正文

共享锁和排他锁 [Shared and Exclusive Locks]

InnoDB 存储引擎实现了两种标准的行级锁，分别为共享锁（S）和排他锁（X）：

共享锁允许事务持有锁进行读行数据
排他锁允许事务持有锁进行更新或删除行数据

比如，事务 T1 在行 r 持有了一个共享锁，那么其他事务 T2 对行 r 请求锁时遵循以下原则：

请求共享锁时，T2 可以立刻获取，此时在行 r 上 T1 和 T2 同时持有共享锁
请求排他锁时，T2 必须等待 T1 的锁释放才可获取

如果 T1 在行 r 持有的是排他锁，T2 对行 r 的任何锁请求都将被阻塞，等待 T1 的锁释放。

意向锁 [Intention Locks]

InnoDB 支持多粒度锁控制，这使得行锁和表锁可以共存。比如，语句 LOCK TABLES … WRITE 将在指定的表上设置一个排他锁。为了实现锁的多粒度控制，InnoDB 使用了意向锁，该类型是一种表锁（table-level locks），表明了事务将要在表的某行设置哪种类型（共享或排他）的锁。InnoDB 支持两种类型的意向锁：

意向共享锁（IS），该锁表明事务将要在表的某行上设置一个共享锁
意向排他锁（IX），该锁表明事务将要在表的某行上设置一个排他锁

比如，SELECT … FOR SHARE 该语句表示设置一个共享锁，SELECT … FOR UPDATE 表示设置一个排他锁。

共享锁遵循以下规范：

事务在表的某行上获得一个共享锁之前，必须先在表上获取一个意向共享（IS）锁或者其他更强类型的锁
事务在表的某行上获得一个排他锁之前，必须先在表上获取一个意向排他（IX）锁

以下表格总结了表级锁间的兼容性：

	X	IX	S	IS
X	冲突	冲突	冲突	冲突
IX	冲突	兼容	冲突	兼容
S	冲突	冲突	兼容	兼容
IS	冲突	兼容	兼容	兼容

一个事务请求的锁如果与表上已存在的锁兼容，则可以立即获取，否则将阻塞等待直到已存在的冲突锁的释放。如果事务因为锁冲突而无法获取锁，可能的原因是发生了死锁或者有错误出现。

意向锁不阻塞任何除全表请求（如 LOCK TABLES … WRITE）外的任何操作，它的主要目的是表明某事务正在或将要锁定表的某一行记录。

以下图示，展示了在执行语句 select * from u where a = 1 for update; 后通过语句 select * from performance_schema.data_locks\G; 观察到当前表上的意向排他锁：
在这里插入图片描述

记录锁 [Record Locks]

record lock 是索引记录（index record）上的一种锁。比如，语句 SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 阻止了其他事务对 t.c1 值为 10 的行数据的插入，更新，删除操作。

record lock 总是对索引记录加锁，如果一个表没有定义任何索引，此时，InnoDB 会创建一个隐式的聚簇索引，record lock 将会使用该索引。

以下图示，展示了之前语句对索引列 a 加锁后，观察到该行上使用了 record lock:
在这里插入图片描述

间隙锁 [Gap Locks]

间隙锁是一种在 索引记录之间，或者第一个索引记录之前，又或者最后一个索引记录之后的间隙上使用的一种锁。比如，语句 SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 阻止了其他事务对列 t.c1 值为 15 的数据的插入操作，不管该列是否已存在该值。这是因为在该范围内所有数据之间的间隙都被锁定了。

一个间隙可能横跨一个索引值，多个索引值，甚至是空的。

间隙锁是性能与并发之间相互妥协的一部分，它只被用在某些事务隔离级别中。

当语句使用唯一索引查找唯一行时，不需要使用间隙锁（这并不包括搜索条件只包含多列组合唯一索引中的部分列）。

比如语句 SELECT * FROM child WHERE id = 100; 如果 id 列有一个唯一索引，则该语句只会对 id 值为 100 的行记录使用 record lock，不管其他事务是否在该行前的间隙插入其他行。

如果 id 列没有索引或者不是唯一索引，该语句则会锁住该行前面的间隙。

还有一点值得注意的是，不同事务对同一个间隙的互相冲突的锁时可以共存的。比如，事务 A 在一个间隙上持有了一个共享间隙锁（gap S-lock）,而事务 B 也可以在同一个间隙上持有一个排他间隙锁（gap X-lock）。可以这么做的原因是，当不同事务对一个记录的间隙锁，在该记录被从索引删除时，间隙锁必须被合并。

间隙锁在 InnoDB 的作用就是单纯的禁止其他事务对已上锁的间隙进行插入操作。共享间隙锁和排他间隙锁之间没有任何区别。他们彼此不会冲突，并且具有相同的功能。

间隙锁在事务隔离级别为 READ COMMITTED 时被禁用，这时，间隙锁在进行索引查找或扫描时被禁用，只有在进行外键约束检查（foreign-key constraint checking）和重复建（duplicate-key checking）检查时会被使用。

当使用 READ COMMITTED 时还会有其他影响。比如，MySQL 在评估 WHERE 条件后，将会释放不符合条件的 record lock，并且对于 UPDATE 语句，InnoDB 将采用“半一致性”进行查找，将会返回数据的最新提交版来判断 UPDATE的 WHERE 条件。

以下图示，展示了对一个不存在的记录加锁时，会对它所属的间隙进行加锁：
在这里插入图片描述

Next-Key Locks

next-key 包含了 record lock 和间隙锁，是这两种锁的组合体。

InnoDB 是这样使用行锁的 — 在查找或扫描索引时，会对索引记录设置共享锁或排他锁。所以，行锁实际上是索引记录锁（the row-level locks are actually index-record locks）。

next-key 锁不仅对索引记录进行加锁，还会对该索引前的间隙进行加锁。

如果一个事务索引 R 持有了一个共享锁或排他锁，那么其他事务就不能在 R 之前的间隙中插入新的索引数据。

举个例子，假设一个索引包含了 10，11，13，20 这四个值，那么 next-key 锁对于该索引将对以下区间进行加锁：

(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)

对于最后一个区间，next-key 锁住了最大索引值之后的间隙，“supremum” 是一个比任何索引值都大的假设值。它并是一个真正的索引记录，所以，实际上 next-lock 只是锁住了最大索引值之后的间隙。

InnoDB 默认的事务隔离级别为 REPEATABLE READ。在该级别下，InnoDB 是 next-key 锁来进行索引的查找和扫描，使用该锁来避免幻象问题。

By default, InnoDB operates in REPEATABLE READ transaction isolation level. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows.

以下图示，展示了对不存在的索引进行加锁时，会使用 next-lock:
在这里插入图片描述