一 锁类型

InnoDB 支持的锁类型包括：

共享锁和排它锁（Shared and Exclusive Locks）

意向锁（Intention Locks）

记录锁（Record Locks）

间隙锁（Gap Locks）

临键锁（Next-Key Locks）

插入意向锁（Insert Intention Locks）

自增锁（AUTO-INC Locks）

空间索引的谓词锁（Predicate Locks for Spatial Indexes）

二 详细描述

2.1 共享锁和排它锁

InnoDB 实现了标准的行级锁，有两种类型：共享锁（S 锁） 和 排它锁（X 锁）。

1、共享锁允许持有锁的事务读取行；

2、排它锁允许持有锁的事务更新或删除一行。

如果事务 T1 持有行 r 上的一个共享锁，那么来自某个不同事务 T2 的对 r 行的锁的请求处理如下：

1、事务 T2 发出的获取 S 锁的请求可以被立即通过。因此事务 T1 和 T2 都持有 r 上的 S 锁

2、事务 T2 发出的获取 X 锁的请求不会被立即通过

如果事务 T1 持有一个行 r 上的排它（X）锁，另一个事务 T2 无论读写请求都不会立即通过。而是 T2 需要等待 T1 释放在行 r 上的锁。

2.2 意向锁

InnoDB 支持多粒度锁，允许行锁和表锁共存。例如，一个类似 LOCK TABLES... WRITE 的语句持有某张表上的一个 X 锁。为了实现多粒度级别的锁定，InnoDB 使用了意向锁。意向锁是表级锁，用于指示事务稍后对表中的行需要哪种类型的锁（共享或独占）。意向锁有两种类型：

1、意向共享锁（IS）表示事务打算在表中的各个行上设置共享锁。

2、意向排他锁（IX）表示事务打算对表中的各个行设置排他锁。

例如，SELECT ... FOR SHARE 设置一个 IS（意向共享锁）锁，而 SELECT ... FOR UPDATE 设置了一个 IX（意向排它锁）锁。

意向锁协议如下：

1、在事务可以获取表中某一行的共享锁之前，它必须首先获取表上的 IS 锁或更强的锁

2、在事务可以获取表中行的排他锁之前，它必须首先获取表上的 IX 锁。

下表总结了表级锁类型兼容性（Conflict 表示冲突，Compatible 表示兼容）：

如果请求事务与现有锁兼容，则将锁授予该事务，但如果该事务与现有锁冲突，则不授予该事务。事务将等待冲突的现有锁被释放。如果锁请求与现有锁冲突，并且由于它会导致死锁而无法授予，则会发生错误。

意向锁不会阻止除完整表请求以外的任何请求（例如，LOCK TABLES ... WRITE）。意向锁的主要目的是显示有人正在锁定一行，或者将要锁定表中的一行。

意向锁的事务数据在 SHOW ENGINE INNODB STATUS 和 INNODB 监控器输出中显示如下：

TABLE LOCK table `test`.`t` trx id 10080 lock mode IX

2.3 记录锁

记录锁是在一条索引记录上的锁。例如，SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 防止任何其他事务对 t.c1 值为 10 的记录进行插入、更新或删除操作。

记录锁始终锁定索引记录，即使定义的表没有索引。在这种情况下，InnoDB 创建一个隐藏的聚簇索引并使用这个索引用于记录锁。

记录锁的事务数据在 SHOW ENGINE INNODB STATUS 和 INNODB 监视器输出中显示如下：

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`trx id 10078 lock_mode X locks rec but not gapRecord lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000a; asc     ;; 1: len 6; hex 00000000274f; asc     'O;; 2: len 7; hex b60000019d0110; asc        ;;

2.4 间隙锁（Gap locks）

间隙锁是在索引记录之间间隙上的锁，或在第一个索引记录之前或最后一个索引记录之后对间隔的锁定。例如，SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 语句，组织其他事物插入 15 到列 t.c1 中，无论在列中是否已经存在 15 这个值，这是因为所有现有值中间范围的间隙都已经被锁定（指针对上面 between 10 到 20 的这个范围）。

间隙可以跨越单个索引值、多个索引值，甚至可以是空的。

间隙锁是性能和并发性之间折衷的一部分，在某些事务隔离级别中使用，而在其他级别中不会使用。

对于使用唯一索引锁定行以搜索唯一行的语句，不需要间隙锁定（这不包括搜索条件只包括多列唯一索引的某些列的情况；在这种情况下，会发生间隙锁定）。 例如，如果 id 列具有唯一索引，则下面的语句仅对 id 值为 100 的行使用索引记录锁，并且与其他会话是否在前面的间隔中插入行无关：

SELECT * FROM child WHERE id = 100;

如果 id 没有索引或者没有唯一索引，那么这条语句将锁住前面的间隙。这里还值得注意的是，冲突的锁可以由不同的事务保留在间隙上。例如，事务 A 可以持有一个间隙上的共享间隙锁（gap S-lock），与此同时事务 B 持有相同间隙上的一个排他间隙锁（gap X-lock）。允许存在冲突的间隙锁的原因是，如果从索引中清除记录，则必须合并由不同事务保留在记录上的间隙锁。

InnoDB 中的 Gap 锁是“纯抑制性的”，这意味着它们的唯一目的是防止其他事务插入到 Gap 中。间隙锁可以共存。一个事务获取的间隙锁并不阻止另一个事务在同一间隙上获取间隙锁。共享和独占间隙锁之间没有区别。它们彼此不冲突，并且执行相同的功能。

可以明确禁用间隙锁定。如果将事务隔离级别更改为 READ COMMITTED（读已提交），则会发生这种情况。在这些情况下，对搜索和索引扫描禁用间隙锁定，并且仅用于外键约束检查和重复键检查。

使用 READ-COMMITTED 隔离级别还有其他效果。在 MySQL 评估 WHERE 条件之后，将释放不匹配行的记录锁。

对 UPDATE 语句，InnoDB 执行“半一致”读取，这样它会将最新提交的版本返回给 MySQL，以便 MySQL 可以确定行是否匹配 UPDATE 语句的 WHERE 条件。

2.5 临键锁（Next-Key Locks）

临键锁是索引记录上一个记录锁和这条索引记录前面间隙上的间隙锁的组合。

InnoDB 执行行级锁定的方式是，当它搜索或扫描表索引时，它会对遇到的索引记录设置共享或排他锁。因此，行级锁实际上是索引记录锁。索引记录上的下一个键锁也会影响该索引记录之前的“间隙”。也就是说，临键锁是索引记录锁加上索引记录前面的间隔上的间隔锁。如果一个会话对索引中的记录 R 具有共享或排它锁，则另一个会话不能在紧靠索引顺序中的 R 之前的间隙中插入新的索引记录。假设索引包含值 10、11、13 和 20。此索引的临键锁可能包含以下区间，其中圆括号表示排除边界点，方括号表示包含边界点：

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

对于最后一个间隙，临键锁锁定索引中最大值上方的间隙和“上确界”伪记录，该伪记录的值高于索引中的任何实际值。上确界不是真正的索引记录，因此，实际上，临键锁只锁定最大索引值后面的间隙。

默认情况下，InnoDB 的隔离级别是 REPEATABLE READ（可重复读）。这种情况下，InnoDB 使用临键锁进行搜索和索引扫描，从而防止幻读（幻影行）。

临键锁的事务数据在 SHOW ENGINE INNODB STATUS 和 INNODB 监视器输出中显示如下：

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`trx id 10080 lock_mode XRecord lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000a; asc     ;; 1: len 6; hex 00000000274f; asc     'O;; 2: len 7; hex b60000019d0110; asc        ;;

2.6 插入意向锁

插入意向锁是在插入行之前由插入操作设置的一种间隙锁。此锁表示插入的意图，如果插入到同一索引间隙中的多个事务不在间隙中的同一位置插入，则它们不需要等待对方。假设存在值为 4 和 7 的索引记录。分别尝试插入值 5 和 6 的独立事务，在获得插入行的独占锁之前，每个事务都使用插入意图锁锁定 4 和 7 之间的间隔，但不会相互阻止，因为这些行不冲突。

下面的示例演示了一个事务，它在获取插入记录上的独占锁之前使用插入意图锁。这个例子涉及两个客户端，A 和 B。

客户端 A 创建一个包含两个索引记录（90 和 102）的表，然后启动一个事务，对 ID 大于 100 的索引记录进行排他锁。排他锁包括记录 102 之前的间隙锁：

mysql> CREATE TABLE child (id int(11) NOT NULL, PRIMARY KEY(id)) ENGINE=InnoDB;mysql> INSERT INTO child (id) values (90),(102);
mysql> START TRANSACTION;mysql> SELECT * FROM child WHERE id > 100 FOR UPDATE;+-----+| id  |+-----+| 102 |+-----+

客户机 B 开启一个事务，将一条记录插入间隙。事务在等待获取排他锁时接受插入意向锁。

mysql> START TRANSACTION;mysql> INSERT INTO child (id) VALUES (101);

插入意向锁的事务数据在 SHOW ENGINE INNODB STATUS 和 INNODB monitor 输出中的显示类似于下面的内容:

RECORD LOCKS space id 31 page no 3 n bits 72 index `PRIMARY` of table `test`.`child`trx id 8731 lock_mode X locks gap before rec insert intention waitingRecord lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 80000066; asc    f;; 1: len 6; hex 000000002215; asc     " ;; 2: len 7; hex 9000000172011c; asc     r  ;;...

2.7 自增锁（AUTO-INC Locks）

自增锁是一种特殊的表级锁，由插入到具有自动增量列的表中的事务产生。在最简单的情况下，如果一个事务正在向表中插入值，则任何其他事务都必须等待自己向该表中插入值，以便第一个事务插入的行接收连续的主键值。

innodb_autoinc_lock_mode 配置项控制用于自动增量锁定的算法。它允许我们选择如何在可预测的自动增量值序列和插入操作的最大并发性之间进行权衡。

2.8 空间索引谓词锁（Predicate Locks for Spatial Indexes）

InnoDB 支持包含空间列的空间索引。为了处理涉及空间索引操作的锁定，临键锁不能很好地支持可重复读 或 序列化事务隔离级别。多维数据中没有绝对的排序概念，因此不清楚哪个是“下一个”键。

为了支持具有空间索引的表的隔离级别，InnoDB 使用谓词锁。空间索引包含最小边界矩形（MBR）值，因此 InnoDB 通过对用于查询的 MBR 值设置谓词锁来强制索引的一致读取。其他事务不能插入或修改与查询条件匹配的行。

三 总结

本章整理了 InnoDB 中的锁类型，和锁的含义及简单示例。在后续的文章中，我们会详细阐述分析每一种锁。