MySQL InnoDB 锁的相关总结-巨人网络通讯

MySQL InnoDB 锁的相关总结

1. Shared and Exclusive Locks

shared lock （译：共享锁）

exclusive lock （译：排它锁、独占锁）

InnoDB实现了标准的行级锁，其中有两种类型的锁，共享锁（shared locks）和排他锁（exclusive locks）。

A shared (S) lock permits the transaction that holds the lock to read a row.

An exclusive (X) lock permits the transaction that holds the lock to update or delete a row.

共享锁允许持有该锁的事务读取一行。

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

如果事务T1持有行 r 上的共享锁(S)，那么来自不同事务T2的请求将按照以下方式处理：

T2对S锁的请求可以立即被授予。结果就是，T1和T2在行r上都持有S锁。
T2对X锁的请求不能立即被授予。

如果事务T1持有行 r 上的排它锁(X)，那么来自不同事务T2的请求不能立即被授予 r 上任何一种类型的锁。相反，事务T2必须等待事务T1释放其在行 r 上的锁。

2. Intention Locks

Intention Locks（译：意向锁）

InnoDB支持多粒度锁，允许行锁和表锁共存。例如，诸如LOCK TABLES ... WRITE之类的语句对指定表采用排它锁（X锁）。为了在多个粒度级别上实现锁，InnoDB使用了意向锁。意向锁是表级锁，它指示事务稍后需要对表中的一行使用哪种类型的锁（共享锁或者排它锁）。

有两种类型的意向锁：

意向共享锁(IS)表示事务打算在表中的单个行上设置共享锁。
意向排他锁(IX)表示事务打算在表中的单个行上设置排它锁。

例如，SELECT ... LOCK IN SHARE MODE 设置一个IS锁，SELECT ... FOR UPDATE 设置一个IX锁。

意向锁的协定是这样的：

在事务获得表中某一行的共享锁之前，它必须首先获得表上的IS锁或更强锁。
在事务获得表中某一行的排它锁之前，它必须首先获得表上的IX锁。
表级锁类型兼容性如下图：

如果一个锁与现有锁兼容，则将其授予请求的事务，但如果与现有锁冲突，则不授予该锁。事务等待，直到冲突的现有锁被释放。如果一个锁请求与一个现有的锁冲突，并且因为它会导致死锁而不能被授予，那么就会发生错误。

意向锁除了全表请求（例如LOCK TABLES ... WRITE）外，不阻止任何其他内容。意图锁定的主要目的是表明某人正在锁定表中的行或要锁定表中的行。

3. Record Locks

Record Locks（译：记录锁）

A record lock is a lock on an index record.

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

记录锁总是锁定索引记录，即使一个表没有定义索引也是如此。如果表没有索引，InnoDB创建一个隐藏的聚集索引，并将该索引用于记录锁。

4. Gap Locks

Gap Locks（译：间隙锁）

A gap lock is a lock on a gap between index records, or a lock on the gap before the first or after the last index record.

间隙锁是在索引记录之间的间隙上的锁，或者是在第一个索引记录之前或最后一个索引记录之后的间隙上的锁。

例如，SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 防止其他事务将值15插入到t.c1列中，无论该列中是否已经有这样的值，因为范围内所有现有值之间的间隙都被锁定了。

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

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

对于使用唯一索引锁定行以搜索唯一行的语句，不需要间隙锁定。

例如，如果id列有一个唯一的索引，下面的语句只对id值为100的行使用index-record锁，而不管其他会话是否在前面的间隙插入行：

SELECT * FROM child WHERE id = 100;

如果id列没有索引或者有一个非唯一索引，则该语句会锁定前面的间隙。

这里还值得注意的是，不同的事务可以在一个间隙上持有冲突的锁。

例如，事务A可以在一个间隙上持有一个共享间隙锁(gap S-lock)，而事务B在同一个间隙上持有一个排他间隙锁(gap X-lock)。允许冲突间隙锁的原因是，如果一条记录从一个索引中被清除，那么记录上由不同事务持有的间隙锁必须被合并。

InnoDB中间隙锁的唯一目的是防止其他事务插入间隙。间隙锁可以共存。一个事务取得的间隙锁并不会阻止另一个事务取得同一间隙上的间隙锁。共享和独占间隔锁之间没有区别。它们彼此之间不冲突，并且执行相同的功能。

5. Next-Key Locks

A next-key lock is a combination of a record lock on the index record and a gap lock on the gap before the index record.

next-key锁是索引记录上的记录锁和索引记录之前的间隙锁的组合。

InnoDB执行行级锁的方式是这样的：当它搜索或扫描一个表索引时，它会在遇到的索引记录上设置共享锁或排他锁。因此，行级锁实际上是索引记录锁。索引记录上的next-key锁也会影响该索引记录之前的“间隙”。也就是说，next-key锁是索引记录锁加上索引记录之前的间隙锁。如果一个会话在一个索引中的记录R上有一个共享锁或排他锁，则另一会话无法按照索引顺序在R之前的间隙中插入新的索引记录。

假设一个索引包含值10、11、13和20。该索引可能的next-key锁覆盖以下区间：

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

默认情况下，InnoDB使用REPEATABLE READ事务隔离级别。在这种情况下，InnoDB使用next-key锁进行搜索和索引扫描，以阻止幻象行。

6. Insert Intention Locks

Insert Intention Locks（译：插入意向锁）

插入意向锁是一种间隙锁，是由INSERT操作在行插入之前设置的。这个锁表示，如果多个事务插入到同一个索引间隙中，如果它们没有插入到这个间隙中的同一位置，那么它们就不需要等待对方。假设有值为4和7的索引记录。尝试插入值分别为5和6的独立事务，在获得插入行的排他锁之前，每个事务都用插入意向锁锁住4和7之间的间隙，但不会阻塞彼此，因为行是不冲突的。