MySQL 锁模式

InnoDB implements standard row-level locking where there are two types of locks, shared (S) locks and exclusive (X) locks. For information about record, gap, and next-key lock types, see Section 14.3.5.6, “InnoDB Record, Gap, and Next-Key Locks”.

 InnoDB 实现了标准行级锁, 他又两种锁, 共享(S)锁和排他(X)锁. 需要看record, gap, next-key锁类型, 参照 xxx

• 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.

• 一个排他锁允许事务获取锁来更新或删除一行 

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 的锁需求会如下处理

• 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对S锁的请求会被马上授权.因此, T1 T2都对r持有一个共享锁

• A request by T2 for an X lock cannot be granted immediately.

• T2对X锁的请求不会被马上授权

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上的锁

Intention Locks

意向锁

Additionally, InnoDB supports multiple granularity locking which permits coexistence of record locks and locks on entire tables. To make locking at multiple granularity levels practical, additional types of locks called intention locksare used. Intention locks are table locks in InnoDB that indicate which type of lock (shared or exclusive) a transaction will require later for a row in that table. There are two types of intention locks used in InnoDB (assume that transaction T has requested a lock of the indicated type on table t):

另外, InnoDB支持多重粒度加锁, 这允许行锁和表所共存. 为了让多重粒度锁定具有实用性, 另外一种叫做意向锁的锁会被使用. 意向锁在InnoDB中是表锁, 他表明S或X锁将会在一个事务中对某一行使用. InnoDB有两种意向锁(假设事务T已经请求了表t的一个锁)

• Intention shared (IS): Transaction T intends to set S locks on individual rows in table t.

• 意向共享锁(IS): 事务T打算设置S锁到表t上

• Intention exclusive (IX): Transaction T intends to set X locks on those rows.

• 意向排他锁(IX): 事务T打算设置X锁到行上 

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

例如, SELECT ... LOCK IN SHARE_MODE 设置一个 IS 锁, 而 SELECT ... FOR UPDATE 设置一个 IX 锁

The intention locking protocol is as follows:

意向锁协议如下

• Before a transaction can acquire an S lock on a row in table t, it must first acquire an IS or stronger lock on t.

• 在一个事务获取表t的某行的S锁之前, 他必须获取表t的一个IS锁或更强的锁

• Before a transaction can acquire an X lock on a row, it must first acquire an IX lock on t.

• 在一个事务获取表t某行的X锁之前, 他必须获取一个t的IX锁

These rules can be conveniently summarized by means of the following lock type compatibility 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.

一个锁如果和已经存在的锁兼容, 就可以授权给请求他的事务, 但如果和已存在的锁不兼容则不行.一个事务必须等待直到冲突的锁被释放.如果一个锁请求和一个已经存在的锁冲突, 并且一直不能被授权, 就会造成死锁.

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

因此, 意向锁并不会阻塞任何事情, 除非是对全表的请求(例如, LOCK TABLES ... WRITE). IX和IS锁的主要目的是表示有人正在锁定一行, 或者准备锁定一行.

Deadlock Example

死锁示例

The following example illustrates how an error can occur when a lock request would cause a deadlock. The example involves two clients, A and B.

下面的实例举例说明了当一个锁请求造成死锁时, 发生错误的情形. 示例包括两个客户端 A, B

First, client A creates a table containing one row, and then begins a transaction. Within the transaction, A obtains an S lock on the row by selecting it in share mode:

首先客户端A创造一个包含一行的表, 并且开始一个事务.在事务内, A通过select in share mode获得了一个S锁

mysql> CREATE TABLE t (i INT) ENGINE = InnoDB;
Query OK, 0 rows affected (1.07 sec)

mysql> INSERT INTO t (i) VALUES(1);
Query OK, 1 row affected (0.09 sec)

mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM t WHERE i = 1 LOCK IN SHARE MODE;
+------+
| i    |
+------+
|    1 |
+------+
1 row in set (0.10 sec)

Next, client B begins a transaction and attempts to delete the row from the table:

接下来B开始一个事务, 并试图删除那行

mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> DELETE FROM t WHERE i = 1;

The delete operation requires an X lock. The lock cannot be granted because it is incompatible with the S lock that client A holds, so the request goes on the queue of lock requests for the row and client B blocks.

删除操作会获取一个X锁, 但是锁并不能被授权, 因为他和A持有的S锁不兼容, 所以请求会继续并且B被阻塞

Finally, client A also attempts to delete the row from the table:

最后, A也尝试从表中删除这行

mysql> DELETE FROM t WHERE i = 1;
ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction

Deadlock occurs here because client A needs an X lock to delete the row. However, that lock request cannot be granted because client B already has a request for an X lock and is waiting for client A to release its S lock. Nor can the S lock held by A be upgraded to an X lock because of the prior request by B for an X lock. As a result,InnoDB generates an error for one of the clients and releases its locks. The client returns this error:

死锁就在这里发生了, 因为A需要X锁来删除这行.然而, 它无法获取X锁, 因为B已经请求了一个X锁, 并且正在等待A释放他的S锁. 同样A的S锁也不能升级为X锁, 因为B的前一个请求请求了一个X锁.因此, InnoDB为其中一个客户端生成了一个错误并释放了他的锁. 错误如下

ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction

At that point, the lock request for the other client can be granted and it deletes the row from the table.

在那时, 别的客户端的锁请求可以被授权并且他将会从表中删除行

Note

If the LATEST DETECTED DEADLOCK section of InnoDB Monitor output includes a message stating, “TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION,”this indicates that the number of transactions on the wait-for list has reached a limit of 200, which is defined byLOCK_MAX_DEPTH_IN_DEADLOCK_CHECK. A wait-for list that exceeds 200 transactions is treated as a deadlock and the transaction attempting to check the wait-for list is rolled back.

如果 LATEST DETECTED DEADLOCK 监视器输出包括这样一个消息 "TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACION" 这说明等待列表中的事务数量超过了200个, 这是有LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK定义的. 一个等待列表达到200个事务, 会被认为是一次死锁, 并且尝试检查等待列表的事务会回滚

The same error may also occur if the locking thread must look at more than 1,000,000 locks owned by the transactions on the wait-for list. The limit of 1,000,000 locks is defined byLOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK.