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:

插入意向锁 [Insert Intention Locks]

插入意向锁是一种间隙锁，在插入数据前由 INSERT 操作进行设置。

该锁表明了不同事务在向同一个间隙插入数据时，若插入的位置不同时，事务之间不需要相互等待。

假如有一个索引包含了 4 和 7 两个值，当其他不同事务分别插入索引为 5 和 6 的数据时，在获取插入行的排他锁之前都会先获取 4 和 7 之间间隙的插入意向锁，当时由于值不同，所以事务并不会互相阻塞。

以下图示，展示了事务 1 对索引范围加锁后，事务 2 在该范围内进行插入，此时在等待获取排他锁时会设置一个插入意向锁：

自增长锁 [AUTO-INC Locks]

自增长锁是一种特殊的表锁，当事务进行插入操作时，若表内含有自增长列就会使用该锁。

在一个最简单的场景中，如果一个事务正在对一个表进行插入操作，那么其他事务在进行插入操作时就必选等待前面事务操作的完成，以使得前面事务可以获取一个连续的主键值。

参数 innodb_autoinc_lock_mode 可以控制锁的算法，它允许你在插入操作时对获取连续自增长值和实现最大并发之间做出选择。

总结

通过以上介绍，我们可以知道 InnoDB 有的行锁分为两种类型：共享锁和排他锁。
有四种不同作用的锁：

• 意向锁
• 索引记录锁 record lock
• 间隙锁
• next-key 锁 = record lock + gap lock
• 插入意向锁

还有自增锁等。

其中间隙锁在 READ COMMITTED 的事务隔离级别下被禁止使用，但外键冲突检测和重复键检测时仍会使用。

参考资料

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html