原文鏈接 https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-shared-exclusive-locks

InnoDB鎖分類

• Shared and Exclusive Locks (共享鎖和獨(dú)占鎖)
• Intention Locks (意向鎖)
• Record Locks(行鎖)
• Gap Locks(間隙鎖)
• Next-key Locks()
• Insert Intention Locks(插入意向鎖)
• AUTO-INC Locks()
• Predicate Locks for Spatial Indexes

Shared and exclusive Locks(共享鎖和獨(dú)占鎖)

InnoDB implementts standard row-level locking where there are two types of locks, shared(s) locks and exclusive(X) locks. (InnoDB實(shí)現(xiàn)了共享鎖和獨(dú)占鎖兩種標(biāo)準(zhǔn)行級(jí)別的鎖)

• A shared (S) lock permits the transaction that holds the lock to read a row. (共享鎖允許事務(wù)持有讀一行數(shù)據(jù)的鎖)
• An exclusive (X) lock permits the transaction that holds the lock up update or delete a row. (獨(dú)占鎖允許事務(wù)持有更新或刪除一行數(shù)據(jù)的鎖)

If transaction T1 hold a shared (s) locl on row r, then requests from some distinct transaction T2 for a lock on row r are handled as follows; (假如事務(wù)T1持有r行的共享鎖),然后另一個(gè)T2事務(wù)同樣請(qǐng)求來獲取r行的鎖渊迁，處理如下：

• A request by T2 for an s lock can be granted immediately. As a result, both T1 and T2 hold on S lock on r ( T2事務(wù)請(qǐng)求獲取S鎖酥郭，可以馬上獲得。這時(shí)候T1和T2兩個(gè)事務(wù)同時(shí)持有r的S鎖)
• A request by T2 for an X lock cannot be granted immeditely. (T2事務(wù)請(qǐng)求獲取X鎖不會(huì)馬上授權(quán))

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 immeditely. Instead, transaction T2 has to wait for transaction T1 to release its lock on row r. (如果T1事務(wù)持有了r行的X鎖层亿，T2事務(wù)再請(qǐng)求獲取r行的鎖不會(huì)馬上獲得，反而，T2事務(wù)必須等待T1事務(wù)釋放鎖才可以獲取r行的鎖)

Intention Locks (意向鎖)

InnoDB supports multiple granularity locking which permits coexistence of row locks and table locks. For example, a statement such as LOCK TABLE ... WRITE takes an exclusive lock (an X lock) on the specified table. To make locking at mutiple granularity levels pratical, InnoDB uses intention locks. 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 TALBES ... WRITE 獲取一個(gè)表的獨(dú)占鎖氓涣。 為了使多粒度級(jí)別的鎖可以使用, InnoDB 使用意向鎖. 意向鎖是表級(jí)別的鎖, 表示在一個(gè)表中執(zhí)行事務(wù)可以通過獲取不同類型的鎖(共享鎖和獨(dú)占鎖). 兩種意向所如下:

• An intention shared lock (IS) indicates that a transaction intends to set a shared lock on individual rows in a table. (意向鎖表示事務(wù)可以通過設(shè)置一個(gè)共享鎖來持有表中的指定行)
• An intention exclusive lock (IX) indicates that a transaction intends to set an exclusive lock on individual rows in table. (意向獨(dú)占鎖表示事務(wù)可以通過一個(gè)獨(dú)占鎖來持有表中的行)

For example, SELECT ... FOR SHARE sets an IS lock, and SELECT ... FOR UPDATE sets an IX lock. (例如，SELECT ... FOR SHARE 設(shè)置一個(gè)IS鎖, SELECT ... FOR UPDATE 設(shè)置一個(gè)獨(dú)占鎖)

The intention locking protocol is as follows: (意向鎖協(xié)議如下)

• 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. (在事務(wù)獲取一個(gè)表的共享鎖之前陋气，必須首先獲取一個(gè)IS鎖或更高級(jí)別的鎖)
• Before a transaction can aquire an exclusive lock on a row in a table, it must first acquire an IX on the tables. (在事務(wù)獲取一個(gè)表的獨(dú)占鎖之前劳吠，必須首先獲取一個(gè)IX鎖或者更高級(jí)別的鎖)

Table-level lock type compatibility is summarized in the following maxtrix. (表級(jí)別的鎖類型的兼容性總結(jié)如下表格)

A lock is granted to a requesting transaction if it is compatible, but not if it conflicts with exisint locks. A transaction waits until the conflicting exsiting lock is released. If a lock request conflicts with an existing lock and cannot be granted because it would cause deadlock, an error occurs. (如果已經(jīng)存在一個(gè)兼容性的鎖，那么請(qǐng)求事務(wù)是可以再次獲取鎖的,但是不是獨(dú)占鎖.事務(wù)必須等到持有的獨(dú)占鎖釋放.如果一個(gè)事務(wù)請(qǐng)求獲取一個(gè)已經(jīng)存在獨(dú)占鎖的數(shù)據(jù)但是無法授權(quán)就會(huì)導(dǎo)致死鎖,出現(xiàn)錯(cuò)誤.)

Intention locks do not block anything except full table requests (for example, LOCK TABLES ... WRITE). The main purpose of intention locks is show that someone is locking a row, or going to lock a row in the table. (除了全表請(qǐng)求(例如, LOCK TABLES ... WRITE)恩伺，意向鎖不會(huì)阻塞任何請(qǐng)求. 意向鎖的主要目的是表明有人正在鎖定一行數(shù)據(jù)赴背，或則正在鎖定表中的一行數(shù)據(jù).)

Transaction data for an intention lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output: (意向鎖的事務(wù)數(shù)據(jù)在 SHOW ENGINE STATUS 和 InnoDB monitor的輸出如下:)

TABLE LOCK tales `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；防止其它事務(wù)的插入燃观，修改或則刪除t.c1=10的行數(shù)據(jù)褒脯。)

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 15.6.2.1,"Clustered and Secondary Indexes". (行鎖只會(huì)鎖住帶有索引的行，即使表沒有定義索引缆毁。這種情況番川，InnoDB會(huì)創(chuàng)建一個(gè)隱藏的clustered索引來使用給行鎖使用。見章節(jié) 15.6.2.1脊框，“聚簇索引和二級(jí)索引”)

Transaction data for a record lock appears similar to the the following is SHOW ENGINE INNODB STATUS and InnoDB monitor output (使用行鎖的事務(wù)數(shù)據(jù)通過 SHOW ENGINE INNODB 和 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
  o: len 4; hex 800000a;  asc      ;;
  1: len 6; hex 00000000274f; asc      '0;;
  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. (間隙鎖是鎖住一個(gè)范圍的索引颁督，或者鎖住第一條數(shù)據(jù)之前的數(shù)據(jù)，或者最后一條數(shù)據(jù)之后的數(shù)據(jù)浇雹。例如沉御，SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE；防止其它事務(wù)再t.c1上插入一條15的值昭灵，無論該列是否已經(jīng)存在任何這樣的值吠裆，因?yàn)樵摲秶鷥?nèi)的值都被鎖上了間隙鎖)

A gap might span a single index value, multiple index values, or even empty. (間隙鎖可能包括單個(gè)索引值，多個(gè)索引值烂完，或者甚至為空)

Gap locks are part of hte tradeoff between performance and concurrency, and are used in some transaction isolation levels and not others. (間隙鎖是性能和并發(fā)權(quán)衡的一部分试疙，并且用于一些事務(wù)的隔離級(jí)別而不是其它級(jí)別)

Gap locking is not needed for statement 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 id does not matter whether other sessions insert rows in the perceding gap: (使用唯一索引搜索唯一行語句不需要使用間隙鎖定，（這不包括搜索條件只包含多列唯一索引的部分列的情況抠蚣，這中情況祝旷，會(huì)出現(xiàn)間隙鎖）例如，如果id列是唯一索引嘶窄，以下語句僅對(duì)id為100的行使用index-record lock怀跛，其它的會(huì)話是否在前面的間隙中插入間隙鎖都沒有關(guān)系)

SELECT * FROM child WHERE id = 100;

If id is not indexed or has nonunique index, the statement does lock the preceding gap. (如果沒有index或則唯一索引，就會(huì)鎖定前面的數(shù)據(jù))

If is also worth noting hear 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. (這里還值得注意的是护侮，不同的事務(wù)可以在間隙鎖上持有沖突的鎖敌完，例如，事務(wù)A持有了間隙共享鎖 gap S-lock在一個(gè)間隙中羊初，事務(wù)B持有了一個(gè)獨(dú)占間隙鎖 gap X-lock也在同樣的間隙上滨溉，如果清除了記錄的索引什湘，間隙鎖沖突是允許的，不同的事務(wù)在記錄上持有的間隙鎖必須合并)

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. The do not conflict with each other, and they perform the same function. (間隙鎖在InnoDB是"purely inhibitive"晦攒，意味著它們的作用是防止其它事務(wù)在間隙鎖范圍插入數(shù)據(jù)闽撤。 間隙鎖可以共存。一個(gè)事務(wù)使用了間隙鎖不會(huì)組織其它事務(wù)在同一個(gè)間隙鎖再次使用間隙鎖脯颜。共享和獨(dú)占間隙鎖沒有區(qū)別哟旗。它們不會(huì)互相沖突，而且他們的功能一樣)

Gap locking can be disable explicitly. This occurs if you change the transaction isolation level to READ COMMITTED. In this case, gap locking is disabled fo searches and index scans and is used only for foreign-key constraint checking and duplicate-key checking. (間隙鎖可以明確關(guān)閉栋操，如果你調(diào)整事務(wù)隔離級(jí)別為 READ COMMITTED闸餐。這種情況，在搜索和索引掃描用于外鍵約束和重復(fù)鍵約束間隙鎖會(huì)失效)

There are also other effects of using the READ COMMITTED isolation level. 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 conditions of the UPDATE. (只影響 READ COMMITTED的隔離級(jí)別矾芙。MySQL會(huì)評(píng)估 WHERE條件后的數(shù)據(jù)舍沙，再釋放不匹配的行鎖。對(duì)于UPDATE語句剔宪， InnoDB會(huì)使用 "semi-consistent" read拂铡，MySQL將返回最新提交的版本,以便MySQL可以確定該行是否滿足更新的條件)

Next-Key Locks ()

A next-key locks is a combination of a record lock on the index record and a gap lock on the gap before the index record. (next-key鎖是由index行的行鎖和在index行之前的間隙鎖組合的)

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 sessionn 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 inthe index order. (InnoDB執(zhí)行行級(jí)別的鎖是通過對(duì)表中索引的搜索和掃描，它在找到的記錄上設(shè)置共享鎖或者獨(dú)占鎖葱绒。因此感帅，行鎖實(shí)際上是index行鎖。 next-key鎖在index記錄上也會(huì)影響在間隙之前的index記錄地淀。也就是說失球，next-key lock是一個(gè)index行鎖加間隙鎖，在間隙鎖之前的index記錄骚秦。如果一個(gè)會(huì)話存在一個(gè)共享鎖或則獨(dú)占鎖在index的R行她倘，其它會(huì)話不能插入新的index記錄在間隙中R之前的排序好的index中)

Suppose that an idnex 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 s square bracket denotes inclusion of the endpoint: (假設(shè)一個(gè)索引包含值10，11作箍，13硬梁，20。next-key鎖盡可能的覆蓋以下的間隔胞得，一個(gè)括號(hào)表示不包含間隔節(jié)點(diǎn)荧止，中括號(hào)表示包含間隔節(jié)點(diǎn))

(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. (對(duì)于最后間隔范圍，next-key lock鎖住間隙最大值以上的索引阶剑，并且“supremum"偽記錄的值大于索引中的任何值跃巡， supremum(至高無上)不是一個(gè)實(shí)際的索引記錄，所以牧愁，實(shí)際上素邪，next-key鎖只會(huì)鎖住間隙中最大的索引值)

By defualt, 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 15.7.4,"phantom Rows"). (默認(rèn)，InnoDB使用REPEATABLE READ事務(wù)隔離級(jí)別猪半，這種情況兔朦， InnoDB使用next-lock鎖搜索和索引掃描偷线，防止幻讀，（見章節(jié) 15.7.4, “幻讀行”）)

Transaction data for a next-key lock appears similar to the following in SHOW ENGINE INNODB STATUS and InnoDB monitor output: (next-key鎖持有的事務(wù)數(shù)據(jù)通過 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 on 2 PHYSICAL RECORD: n_field 3; compact format; info bits 0
  0: len 4; hex 8000000a; asc    ;;
  1:  len 6; hex 0000000274f; asc    '0;;
  2: len 7; hex b60000029d0110; 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 he 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 nonconfliting. (插入意向鎖是只用在INSERT操作之前的的間隙鎖沽甥。此鎖表示插入意向声邦，在多個(gè)事務(wù)插入在同一個(gè)索引間隙的不同位置的時(shí)候不需要等待，假設(shè)行鎖的位置是4和7摆舟。其它的事務(wù)嘗試分別插入值5和6亥曹，在4到7之間的間隙鎖范圍內(nèi)，插入行時(shí)意向鎖比獨(dú)占鎖優(yōu)先獲取恨诱，應(yīng)為行沒有沖突每個(gè)事務(wù)就不會(huì)阻塞)

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. (下面的例子演示了一個(gè)事務(wù)在插入數(shù)據(jù)的時(shí)候插入意向鎖比獨(dú)占鎖優(yōu)先獲取媳瞪。這個(gè)例子設(shè)計(jì)兩個(gè)客戶端，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創(chuàng)建一個(gè)表包含兩個(gè)索引記錄90和20材失，然后開啟事務(wù)使用獨(dú)占鎖查詢id大于100的索引記錄痕鳍，這個(gè)獨(dú)占鎖包括了一個(gè)在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 TRANSACIONT;
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開啟事務(wù)硫豆，在間隙插入一條記錄，事務(wù)獲取到插入意向鎖后開始等待直到獲取到獨(dú)占鎖)

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: (插入意向鎖的事務(wù)數(shù)據(jù)在 SHOW ENGINE INNODB STATUS 和 InnoDB 監(jiān)視器輸出中顯示類似于以下內(nèi)容：)

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鎖是一個(gè)特殊的表級(jí)別的鎖阳似，在通過事務(wù)插入數(shù)據(jù)到表中的AUTO_INCREMENT列使用绝淡。在最簡單的情況下埃脏，如果一個(gè)事務(wù)在表中插入數(shù)據(jù)，其它事務(wù)必須等待表中的插入完成汗茄，以便第一個(gè)事務(wù)插入的行接收連續(xù)的主鍵值)

The innodb_autoinc_lock_mode variable 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變量控制auto-increment 鎖的算法，它允許你選擇如何在可預(yù)測連續(xù)的自動(dòng)增量和插入的最大并發(fā)之間進(jìn)行權(quán)衡)

For more infomation, see Seciont 15.6.1.6, "AUTO_INCREMENT Handing in InnoDB".

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

InnoDB supports SPATIAL indexing of columns containing spatial data (see Section 11.4.9, "Optimizing Spatial Analysis"). (InnoDB支持空間索引包含空間數(shù)據(jù)铭若，見章節(jié) 11.4.9 "空間分析優(yōu)化")

To handle locking for operations invoving SPATIAL indexes, next-key locking does not work well to support REPEATABLE READ or SERILIZABLE transaction isolation level. There is no absolute ordering concept in multidimensional data, so it is not clear which is the "next" key. (處理涉及到空間索引的操作洪碳，next-key鎖在REPEATABLE READ或則SERIALIZABLE的事務(wù)隔離級(jí)別效果不是很好，多維數(shù)據(jù)中沒有絕對(duì)排序的概念叼屠，所以無法確認(rèn)下一個(gè)鍵)

To enable support of isolation levels for tables with SPATIAL indexs, 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 MBR value used for a query. Other transactions cannot insert or modify a row that would match the query condition. (為了確保事務(wù)級(jí)別支持空間索引瞳腌，InnoDB使用predicate鎖，空間索引包含最小多邊矩形的值镜雨，這樣InnoDB強(qiáng)制在空間索引上通過predicate鎖來執(zhí)行查詢空間數(shù)據(jù)嫂侍。其它事務(wù)不能插入或修改符合查詢條件的行)