14.5.1 InnoDB Locking

This section describes lock types used by InnoDB.
這個章節描述了innob的鎖類型

• 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實現標準的行鎖主要有兩種類型，共享鎖和排他鎖

• 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行的共享鎖，如果一個不同的事務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擁有r行的排他鎖，不能立即授予來自某些不同事務 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使用intention locks。 意向鎖是表級鎖，用於指示事務對錶中某一行的事務需要哪種類型的鎖（共享或排他）。意向鎖有兩種類型:
  • 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 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.
• 表級鎖類型兼容性在下面的矩陣中進行了總結。

• 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鎖的主要目的是表示有人正在鎖定一行, 或者準備鎖定一行.
  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

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.8.2.1, “Clustered and Secondary Indexes”.
• 記錄鎖始終鎖定索引記錄，如果一個表沒有定義任何的索引，像這種情況，innodb會創建一個隱藏的聚簇索引並且使用此索引進行記錄鎖定。更多信息請看 Section 14.8.2.1, “Clustered and Secondary Indexes”.
• 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的那行上面加一個索引記錄鎖,而不會關心別的會話（session）是否在前面的間隙中插入數據。
• 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 they only stop other transactions from inserting to the gap. They do not prevent different transactions from taking gap locks on the same gap. Thus, a gap X-lock has the same effect as a gap S-lock.
• 間隙鎖是 ”完全禁止性的“，意味着他們只會禁止其他的事務插入數據到間隙之中，它們不會阻止不同的事務在同一間隙上進行間隙鎖定。。因此，間隙 X鎖和間隙 S鎖起到的效果是一樣的。
• 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.
• 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鎖包含以下間隔。圓括號表示排除間隔端點, 而正方形括號表示包含端點:
• 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鍵鎖將間隔鎖在索引中最大的值之上，而“supremum”僞記錄的值將高於索引中實際的任何值。supremum不是一個真實存在的索引記錄，所以，實際上，這個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.5.4, “Phantom Rows”).
• 默認情況下，InnoDB啓用 REPEATABLE READ 事務隔離等級。在這種情況下，InnoDB在查找和掃描索引時會使用 nex-keys鎖，能避免 幻行的出現。
• Transaction data for a next-key lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output:
• next-key鎖的事務數據在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 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.
• 插入意圖鎖定是插入行之前由INSERT操作設置的一種間隙鎖定。。此鎖表示要插入的意圖是多個事務插入到相同的索引間隙時, 如果它們沒有插入到間隙中的同一位置, 則不必等待對方。。假設存在值爲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之前的間隔鎖：
• 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開始一個事務，將記錄插入到間隙。事務在等待獲取獨佔鎖的同時，獲得插入意圖鎖。
• 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-INC鎖是由插入到帶有 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.8.1.5, “AUTO_INCREMENT Handling in InnoDB”.
• 關於更多信息，請看Section 14.8.1.5, “AUTO_INCREMENT Handling in InnoDB”.

Predicate Locks for Spatial Indexes(空間索引的預測鎖)

• InnoDB supports SPATIAL indexing of columns containing spatial columns (see Section 11.5.8, “Optimizing Spatial Analysis”).
• InnoDB支持空間列上面的空間索引。
• 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.
• 在處理包括空間索引的相關鎖定操作時，next-key鎖 REPEATABLE READ 和 SERIALIZABLE 事務隔離等級上工作的不太好。在多維的數據上，沒有一個絕對的順序，因此，“next”鍵在哪裏並不是很清楚。
• 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.
• 爲了使得空間索引支持隔離級別，InoDB使用預測鎖。一個空間索引包含最小邊界矩形 (MBR)值，所以InnoDB通過在MBR上設置預測鎖來查詢數據，強制一致性讀。其它事務不能插入或修改與查詢條件匹配的行。

PREV：14.5 InnoDB Locking and Transaction Model https://blog.51cto.com/itzhoujun/2353751
NEXT: 14.5.2 InnoDB Transaction Model https://blog.51cto.com/itzhoujun/2354184