To implement a large-scale, busy, or highly reliable database application, to port substantial【s?b?st?n?l】 code from a different database system, or to tune MySQL performance, it is important to understand InnoDB locking and the InnoDB transaction model.

1.Shared and Exclusive Locks

InnoDB implements【??mpl?ments 實(shí)施;執(zhí)行;貫徹;使生效;】 standard row-level locking where there are two types of locks, shared (S) locks and exclusive (X) locks.

?? A shared (S) lock permits the transaction that holds the lock to【to 此時(shí)的意思是為了，表目的】 read a row.

? An exclusive (X) lock permits the transaction that holds the lock to【to 此時(shí)的意思是為了，表目的】 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:

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

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

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.

2.?Intention Locks

Intention--【?n?ten?n 打算;意圖;目的;計(jì)劃;】

InnoDB supports multiple granularity locking which permits coexistence【?ko??ɡ?z?st?ns 共存;共處;】 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【?m?lt?pl 數(shù)量多的;多種多樣的;】 granularity【gr?nj?'l?r?t? 粒度；（顆，成）粒性;】 levels practical【?pr?kt?kl 實(shí)際的;適用的;切實(shí)可行的;有用的;真實(shí)的;明智的;幾乎完全的;客觀存在的;心靈手巧的;】, 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:

? An intention shared lock (IS) indicates that a transaction intends to set a shared lock on individual【??nd??v?d?u?l 單獨(dú)的;個(gè)別的;獨(dú)特的;一個(gè)人的;與眾不同的;供一人用的;】 rows in a table.

? An intention exclusive lock (IX) indicates that a transaction intends to set an exclusive lock on individual rows in a table.

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

The intention locking protocol【?pro?t?kɑ?l 協(xié)議;議定書(shū);規(guī)程;規(guī)約;禮儀;】 is as follows:

? Before a transaction can acquire【??kwa??r (通過(guò)努力、能力、行為表現(xiàn))獲得;得到;購(gòu)得;】 a shared lock on a row in a table, it must first acquire an IS lock or stronger on the table.

? Before a transaction can acquire【??kwa??r?(通過(guò)努力、能力、行為表現(xiàn))獲得;得到;購(gòu)得;】 an exclusive lock on a row in a table, it must first acquire an IX lock on the table.

Table-level lock type compatibility is summarized in the following matrix【?me?tr?ks 矩陣;基體;雜基;(人或社會(huì)成長(zhǎng)發(fā)展的)社會(huì)環(huán)境，政治局勢(shì);線路網(wǎng);矩陣轉(zhuǎn)接電路;道路網(wǎng);】.

A lock is granted to a requesting transaction if it is compatible【k?m?p?t?bl 兼容的，可共存的;】 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:

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

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

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.

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

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

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

A gap might span【sp?n 跨度，范圍;跨距，寬度;】 a single index value, multiple index values, or even be empty.

Gap locks are part of the tradeoff【?tre??d?f 權(quán)衡;協(xié)調(diào);交易;交換;】 between performance and concurrency【計(jì)）并發(fā)性，并行性;】, 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.)? --這一段話，要嘻嘻揣摩，唯一index的查詢，是否需要設(shè)置gap lock。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【pr??si?d?? 在前的;前面的;】 gap:

SELECT * FROM child WHERE id = 100;

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

It is also worth noting here that conflicting【k?n?fl?kt?? 互相斗爭(zhēng)的；相沖突的;】 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【p??rd?d 清除，清洗(組織中的異己分子);凈化(心靈、風(fēng)氣等);滌蕩(污穢);】 from an index, the gap locks held on the record by different transactions must be merged【m??rd?d (使)合并，結(jié)合，并入;融入;相融;漸漸消失在某物中;】.

Gap locks in InnoDB are “purely【?pj?rli 完全;僅僅;】 inhibitive【抑制性的;有阻化性的;】”, which means that their only purpose is to prevent other transactions from inserting to the gap. Gap locks can co-exist【?si? ?o? ?ɡ?z?st 共存;同時(shí)存在;】. 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.--沒(méi)區(qū)別，功能一樣的。

Gap locking can be disabled explicitly. This occurs if you change the transaction isolation level to READ COMMITTED. In this case, gap locking is disabled for searches and index scans and is used only for foreign-key constraint checking and duplicate-key checking.

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 condition of the UPDATE.

5.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 【pr??si?d???在前的;前面的;】?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.

Suppose that an index contains the values 10, 11, 13, and 20. The possible next-key locks for this index cover the following intervals【??nt?rv?lz (時(shí)間上的)間隔，間隙，間歇;(戲劇、電影或音樂(lè)會(huì)的)幕間休息，休息時(shí)間;(其他事情)穿插出現(xiàn)的間隙;】, where a round【ra?nd 圓形的;整數(shù)的;環(huán)形的;圓弧的;球形的;弧形的;】 bracket【?br?k?t 括號(hào);】 denotes【d??no?ts 表示;標(biāo)志;意指;象征;預(yù)示】 exclusion【?k?sklu??n 排斥;排除;排除在外;被排除在外的人(或事物);認(rèn)為不可能;不包括在內(nèi)的人(或事物);】 of the interval endpoint and a square bracket denotes inclusion of the endpoint:

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

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

6.Insert Intention Locks

?An insert intention【?n?ten?n 打算;意圖;目的;計(jì)劃;】 lock is a type of gap lock set by INSERT operations prior to row insertion. This lock signals【?s?ɡn?lz 顯示;表示;表明;標(biāo)志;表達(dá);發(fā)信號(hào);示意;預(yù)示;發(fā)暗號(hào);】 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.

The following example demonstrates【?dem?nstre?ts 證明;演示;示范;論證;表現(xiàn);說(shuō)明;證實(shí);表達(dá);表露;顯露;】 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.

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:

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.

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:

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

7.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【k?n?sekj?t?v 連續(xù)的;連續(xù)不斷的;】 primary key values.

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【pr??d?kt?bl 可預(yù)測(cè)的;可預(yù)見(jiàn)的;可預(yù)料的;意料之中的;老套乏味的;】 sequences of auto-increment values and maximum concurrency for insert operations.

8.Predicate Locks for Spatial Indexes

InnoDB supports SPATIAL indexing of columns containing spatial data.

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【?m?ltid??m?n??n?l 多維的；多面的;】 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【?pred?k?t , ?pred?ke?t 述語(yǔ)的;謂項(xiàng)的;】 locks. A SPATIAL index contains minimum bounding【?ba?nd?? 形成…的邊界(或界限);跳躍著跑;】 rectangle【?rekt??ɡl 長(zhǎng)方形;矩形;】 (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.

?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-855105.html

到了這里，關(guān)于MySQL 8.0 Reference Manual（讀書(shū)筆記63節(jié)--InnoDB Locking）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！