Mysql 官方手册——InnoDB锁翻译

This section describes lock types used by InnoDB.【本节介绍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【空间索引断言锁】

Shared and Exclusive Locks 共享锁和排它锁

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

【InnoDB实现了标准的行级锁，其中有两种类型的锁，共享锁（S）和排他锁（X）。】

• 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.
  【排他(X)锁允许持有该锁的事务更新或删除一行。】

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上的共享锁，那么来自不同事务T2对行r上的锁的请求处理如下:】

• A request by T2 for an S lock can be granted immediately. As a result, both T1 and T2 hold an S lock on r.
  【T2对共享锁的请求可以立即被授予。因此，T1和T2都在r上持有共享锁。】

• A request by T2 for an X lock cannot be granted immediately.
  【T2对排他锁的请求不能立即被授予。】

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持有row r上的排他(X)锁，那么来自不同事务T2对r行上任何一种锁类型的请求不能立即被授予。相反，事务T2必须等待事务T1释放其在r行上的锁。】

Intention Locks 意向锁

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使用了意向锁。意向锁是表级锁，它指示事务稍后需要对表中的一行使用哪种类型的锁(共享锁还是排他锁)。意向锁有两种类型:】

• An intention shared lock (IS) indicates that a transaction intends to set a shared lock on individual rows in a table.
  【意向共享锁(IS)表示事务打算在表中的某行上设置共享锁】

• An intention exclusive lock (IX) indicates that a transaction intends to set an exclusive lock on individual rows in a table.
  【意向排他锁(IX)表示事务打算在表中的某行上设置一个排他锁。】

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

【例如：SELECT…LOCK IN SHARE MODE 设置意向共享锁，SELECT…FOR UPDATE 设置意向排他锁】

个人理解，如果查询使用这些语句，则数据库引擎会自动加上意向锁。

The intention locking protocol is as follows: 【意向锁协议如下：】

• Before a transaction can acquire a shared lock on a row in a table, it must first acquire an IS lock or stronger on the table.
  【在事务获得表中某一行的共享锁之前，它必须首先获得表上的IS锁或更强锁。】

• Before a transaction can acquire an exclusive lock on a row in a table, it must first acquire an IX lock on the table.
  【在事务获得表中某一行的排他锁之前，它必须首先获得表上的IX锁。】

Table-level lock type compatibility is summarized in the following matrix.
【表级锁类型兼容性总结如下表。】

	X	IX	S	IS
X	Conflict	Conflict	Conflict	Conflict
IX	Conflict	Compatible	Conflict	Compatible
S	Conflict	Conflict	Compatible	Compatible
IS	Conflict	Compatible	Compatible	Compatible

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.
意向锁不会阻塞除全表请求之外的任何请求(例如，锁表…写)。意向锁的主要目的是显示某人正在锁定某一行，或者将要锁定表中的某一行。

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

上面的sql代码块是执行SHOW ENGINE INNODB STATUS的部分输出

Record Locks 记录锁

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.

翻译：【记录锁是索引记录上的锁。例如，SELECT c1 FROM t WHERE c1 = 10 For UPDATE;防止任何其他事务插入、更新或删除t.c1值为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”.

翻译：【记录锁总是锁定索引记录，即使一个表没有定义索引。在这种情况下，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        ;;

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. 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可以在一个间隙上持有一个共享间隙锁(gap S-lock)，而事务B在同一个间隙上持有一个排他间隙锁(gap 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条件。】

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.
【临键锁是索引记录上的记录锁和索引记录之前的间隙锁的组合。】

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执行行级锁的方式是这样的:当它搜索或扫描一个表索引时，它会在遇到的索引记录上设置共享锁或排他锁。因此，行级锁实际上是索引记录锁。索引记录上的临键锁也会影响该索引记录之前的“间隙”。也就是说，临键锁是索引记录锁加上索引记录之前的间隙锁。如果一个会话在一个索引中的记录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.

翻译：【对于最后一个区间，临键锁锁定了索引间隙中最大值之上，“上界线”伪记录的值高于索引中任何实际值。至高无上并不是一个真正的索引记录，因此，实际上，这个临键锁只锁定最大索引值后面的间隙。】

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使用REPEATABLE READ事务隔离级别。在这种情况下，InnoDB使用临键锁进行搜索和索引扫描，这样可以防止幻读(见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输出中，next-key锁的事务数据类似如下:】

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

Insert Intention Locks 插入意向锁

An insert intention lock is a type of gap lock set by INSERT operations prior to row insertion. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that attempt to insert values of 5 and 6, respectively, each lock the gap between 4 and 7 with insert intention locks prior to obtaining the exclusive lock on the inserted row, but do not block each other because the rows are nonconflicting.

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

The following example demonstrates a transaction taking an insert intention lock prior to obtaining an exclusive lock on the inserted record. The example involves two clients, A and B.

翻译：【下面的示例演示了一个事务在对插入的记录获取排他锁之前获取插入意向锁。该示例涉及两个客户端，A和B。】

Client A creates a table containing two index records (90 and 102) and then starts a transaction that places an exclusive lock on index records with an ID greater than 100. The exclusive lock includes a gap lock before record 102:

客户端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 |
+-----+

Client B begins a transaction to insert a record into the gap. The transaction takes an insert intention lock while it waits to obtain an exclusive lock.

翻译：【客户B开始一个事务，向间隙中插入一条记录。事务在等待获取排他锁时使用一个插入意向锁。】

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

Transaction data for an insert intention 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 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  ;;...

AUTO-INC Locks 自增锁

An AUTO-INC lock is a special table-level lock taken by transactions inserting into tables with AUTO_INCREMENT columns. In the simplest case, if one transaction is inserting values into the table, any other transactions must wait to do their own inserts into that table, so that rows inserted by the first transaction receive consecutive primary key values.

翻译：【自增锁是一种特殊的表级锁，由插入到带有AUTO_INCREMENT列的表中的事务获得。在最简单的情况下，如果一个事务正在向表中插入值，那么任何其他事务都必须等待自己对该表的插入，以便由第一个事务插入的行接收连续的主键值。】

The innodb_autoinc_lock_mode configuration option controls the algorithm used for auto-increment locking. It allows you to choose how to trade off between predictable sequences of auto-increment values and maximum concurrency for insert operations.

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

For more information, see Section 14.6.1.6, “AUTO_INCREMENT Handling in InnoDB”.
【更多相关信息，请查看14.6.1.6章节介绍 InnoDB如何处理自增】

Predicate Locks for Spatial Indexes 空间索引断言锁

InnoDB supports SPATIAL indexing of columns containing spatial columns (see Section 11.4.8, “Optimizing Spatial Analysis”).
【InnoDB支持对包含空间列的列进行空间索引(见11.4.8节“优化空间分析”)。】

To handle locking for operations involving SPATIAL indexes, next-key locking does not work well to support REPEATABLE READ or SERIALIZABLE transaction isolation levels. There is no absolute ordering concept in multidimensional data, so it is not clear which is the “next” key.

翻译：【要处理涉及空间索引的操作的锁定，临键锁不能很好地支持可重复读或可序列化的事务隔离级别。多维数据中没有绝对的排序概念，所以不清楚哪个键是“下一个”键。】

To enable support of isolation levels for tables with SPATIAL indexes, InnoDB uses predicate locks. A SPATIAL index contains minimum bounding rectangle (MBR) values, so InnoDB enforces consistent read on the index by setting a predicate lock on the MBR value used for a query. Other transactions cannot insert or modify a row that would match the query condition.

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