mysql锁官方文档与理解之InnoDB锁

• Shared and Exclusive Locks（共享锁和排他锁）

• Intention Locks（意向锁）

• Record Locks（记录锁）

• Gap Locks（间隙锁）

• Next-Key Locks（next-key锁）

• Insert Intention Locks（插入意向锁）

• AUTO-INC Locks（AUTO-INC锁）

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

InnoDB implements standard row-level locking where there are two types of locks, shared (S) locks and exclusive (X) locks.

翻译：InnoDB实现了标准的行级锁，其中有两种锁，共享锁和独占锁。

If transaction T1 holds a shared (S) lock on row r, then requests from some distinct transaction T2 for a lock on row r are handled as follows:

翻译：如果事务T1在r行上持有一个共享的(S)锁，那么从某个不同的事务T2请求在r行上持有一个锁的处理如下:

If a transaction T1 holds an exclusive (X) lock on row r, a request from some distinct transaction T2 for a lock of either type on r cannot be granted immediately. Instead, transaction T2 has to wait for transaction T1 to release its lock on row r.

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

InnoDB supports multiple granularity locking which permits coexistence of row locks and table locks. For example, a statement such as LOCK TABLES ... WRITE takes an exclusive lock (an X lock) on the specified table. To make locking at multiple granularity levels practical, InnoDB uses intention locks. Intention locks are table-level locks that indicate which type of lock (shared or exclusive) a transaction requires later for a row in a table. There are two types of intention locks:

翻译：InnoDB支持多粒度锁，允许行锁和表锁共存。例如，像 LOCK TABLES ... WRITE这样的语句接受指定表上的独占锁(X锁)。为了实现多粒度级别的锁，InnoDB使用意向锁。意图锁是表级锁，指示事务稍后需要哪种类型的锁(共享的或排他的)来锁定表中的某一行。意图锁有两种类型：

For example, SELECT ... LOCK IN SHARE MODE sets an IS lock, and SELECT ... FOR UPDATE sets an IX lock.

翻译：例如，SELECT ... LOCK IN SHARE MODE设置IS锁，SELECT ... FOR UPDATE设置IX锁。

The intention locking protocol is as follows:

翻译：意向锁协议如下:

Table-level lock type compatibility is summarized in the following matrix.

翻译：表级锁类型兼容性在下面的矩阵中进行了总结。

A lock is granted to a requesting transaction if it is compatible with existing locks, but not if it conflicts with existing locks. A transaction waits until the conflicting existing lock is released. If a lock request conflicts with an existing lock and cannot be granted because it would cause deadlock, an error occurs.

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

Intention locks do not block anything except full table requests (for example, LOCK TABLES ... WRITE). The main purpose of intention locks is to show that someone is locking a row, or going to lock a row in the table.

翻译：意向锁不阻塞任何东西，除了全表请求(例如，LOCK TABLES ... WRITE)。意图锁的主要目的是显示某人正在锁定或准备锁定表中的一行。

Transaction data for an intention lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output:

翻译：意图锁的事务数据在SHOW ENGINE INNODB STATUS 和 InnoDB monitor输出中类似如下:

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

A record lock is a lock on an index record. For example, SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; prevents any other transaction from inserting, updating, or deleting rows where the value of t.c1 is 10.

Record locks always lock index records, even if a table is defined with no indexes. For such cases, InnoDB creates a hidden clustered index and uses this index for record locking. See Section 14.6.2.1, “Clustered and Secondary Indexes”.

翻译：记录锁是在一个索引记录上加的锁。例如,SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;防止任何其他事务插入、更新或删除t.c1值为10的行。记录锁总是锁定索引记录，即使表没有定义索引。

对于这种情况，InnoDB创建一个隐藏的聚集索引并使用这个索引来锁定记录。参见14.6.2.1节“聚集和二级索引”。

Transaction data for a record lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output:

翻译：记录锁的事务数据在SHOW ENGINE INNODB STATUS和InnoDB monitor输出中类似如下

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 gap
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        ;;

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. For example, SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; prevents other transactions from inserting a value of 15 into column t.c1, whether or not there was already any such value in the column, because the gaps between all existing values in the range are locked.

翻译：间隙锁是在索引记录之间间隙的锁，或者对第一个索引记录之前或最后一个索引记录之后的间隙的锁。例如,SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;防止其他事务在列t.c1中插入15的值，无论列中是否已经有这样的值，因为范围内所有现有值之间的间隙都被锁定。

A gap might span a single index value, multiple index values, or even be empty.

翻译：一个间隙可能跨越一个索引值、多个索引值，甚至是空的。

Gap locks are part of the tradeoff between performance and concurrency, and are used in some transaction isolation levels and not others.

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

Gap locking is not needed for statements that lock rows using a unique index to search for a unique row. (This does not include the case that the search condition includes only some columns of a multiple-column unique index; in that case, gap locking does occur.) For example, if the id column has a unique index, the following statement uses only an index-record lock for the row having id value 100 and it does not matter whether other sessions insert rows in the preceding gap:

翻译：对于使用惟一索引来搜索惟一行来锁定行的语句，则不需要间隙锁定。(这不包括搜索条件只包括多列唯一索引的一些列;在这种情况下，间隙锁定确实会发生。) 例如，如果id列有一个唯一的索引，下面的语句只对id值为100的行使用索引-记录锁，其他会话是否在前面的间隙插入行并不重要:

SELECT * FROM child WHERE id = 100;

If id is not indexed or has a nonunique index, the statement does lock the preceding gap.

翻译：如果id没有索引或具有非惟一索引，该语句会锁定前面的间隙。

It is also worth noting here that conflicting locks can be held on a gap by different transactions. For example, transaction A can hold a shared gap lock (gap S-lock) on a gap while transaction B holds an exclusive gap lock (gap X-lock) on the same gap. The reason conflicting gap locks are allowed is that if a record is purged from an index, the gap locks held on the record by different transactions must be merged.

翻译：这里还值得注意的是，不同的事务可以在间隙上持有冲突锁。例如，事务A可以在一个间隙上持有一个共享的间隙锁(间隙S-lock)，同时事务B可以在同一个间隙上持有一个排他的间隙锁(间隙X-lock)。允许存在冲突间隙锁的原因是，如果从索引中清除一条记录，则必须合并记录上由不同事务持有的间隙锁。

Gap locks in InnoDB are “purely inhibitive”, which means that their only purpose is to prevent other transactions from inserting to the gap. Gap locks can co-exist. A gap lock taken by one transaction does not prevent another transaction from taking a gap lock on the same gap. There is no difference between shared and exclusive gap locks. They do not conflict with each other, and they perform the same function.

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

Gap locking can be disabled explicitly. This occurs if you change the transaction isolation level to READ COMMITTED or enable the innodb_locks_unsafe_for_binlog system variable (which is now deprecated). Under these circumstances, gap locking is disabled for searches and index scans and is used only for foreign-key constraint checking and duplicate-key checking.

翻译：可以显式禁用间隙锁定。如果您更改事务隔离级别为READ COMMITTED或启用innodb_locks_unsafe_for_binlog系统变量(该变量现在不赞成使用)，就会发生这种情况。在这些情况下，间隙锁定对于搜索和索引扫描是禁用的，只用于外键约束检查和重复键检查。

There are also other effects of using the READ COMMITTED isolation level or enabling innodb_locks_unsafe_for_binlog. Record locks for nonmatching rows are released after MySQL has evaluated the WHERE condition. For UPDATE statements, InnoDB does a “semi-consistent” read, such that it returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE.

翻译：使用READ COMMITTED隔离级别或启用innodb_locks_unsafe_for_binlog还有其他影响。在MySQL评估了WHERE条件后，将释放非匹配行的记录锁。对于UPDATE语句，InnoDB执行“半一致”读取，这样它就会返回最新提交的版本给MySQL，这样MySQL就可以确定行是否与UPDATE的WHERE条件匹配。

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 performs row-level locking in such a way that when it searches or scans a table index, it sets shared or exclusive locks on the index records it encounters. Thus, the row-level locks are actually index-record locks. A next-key lock on an index record also affects the “gap” before that index record. That is, a next-key lock is an index-record lock plus a gap lock on the gap preceding the index record. If one session has a shared or exclusive lock on record R in an index, another session cannot insert a new index record in the gap immediately before R in the index order.

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

Suppose that an index contains the values 10, 11, 13, and 20. The possible next-key locks for this index cover the following intervals, where a round bracket denotes exclusion of the interval endpoint and a square bracket denotes inclusion of the endpoint:

翻译：假设索引包含值10、11、13和20。这个索引可能的next-key锁包括以下的时间间隔，其中圆括号表示间隔端点的排除，方括号表示端点的包含:

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

For the last interval, the next-key lock locks the gap above the largest value in the index and the “supremum” pseudo-record having a value higher than any value actually in the index. The supremum is not a real index record, so, in effect, this next-key lock locks only the gap following the largest index value.

翻译：对于最后一个间隔，next-key锁锁定索引中最大值和“上极”伪记录(其值比实际索引中的任何值都高)之间的间隙。上限值并不是一个真正的索引记录，因此，这个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 (see Section 14.7.4, “Phantom Rows”).

翻译：默认情况下，InnoDB操作在可重复读事务隔离级别。在这种情况下，InnoDB使用next-key锁进行搜索和索引扫描，这可以防止幻像行(见14.7.4节“幻像行”)。

Transaction data for a next-key lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output:

翻译：下一键锁定的事务数据在SHOW ENGINE INNODB STATUS和InnoDB monitor输出中类似如下:

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10080 lock_mode X
Record 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        ;;

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 |
+-----+

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

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 waiting
Record 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  ;;...