一文理解MySQL的鎖機(jī)制與死鎖排查

MySQL的并發(fā)控制是在數(shù)據(jù)安全性和并發(fā)處理能力之間的權(quán)衡，通過(guò)不同的鎖策略來(lái)決定對(duì)系統(tǒng)開(kāi)銷和性能的影響。

基礎(chǔ)知識(shí)

為了后續(xù)的解釋更加容易理解，這里列舉一些基本概念的解釋。

悲觀鎖

悲觀鎖指的是對(duì)數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度，因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。

select...for update是MySQL提供的實(shí)現(xiàn)悲觀鎖的方式。在悲觀鎖的情況下，為了保證事務(wù)的隔離性，其它事務(wù)無(wú)法修改這些數(shù)據(jù)。

現(xiàn)在互聯(lián)網(wǎng)高并發(fā)的架構(gòu)中，受到fail-fast思路的影響，悲觀鎖已經(jīng)比較少見(jiàn)了。

樂(lè)觀鎖

相對(duì)悲觀鎖而言，樂(lè)觀鎖機(jī)制采取了更加寬松的加鎖機(jī)制。悲觀鎖依靠數(shù)據(jù)庫(kù)的鎖機(jī)制實(shí)現(xiàn)，以保證操作最大程度的獨(dú)占性。但隨之而來(lái)的就是數(shù)據(jù)庫(kù)性能的大量開(kāi)銷，特別是對(duì)長(zhǎng)事務(wù)而言，這樣的開(kāi)銷往往無(wú)法承受。

而樂(lè)觀鎖機(jī)制在一定程度上解決了這個(gè)問(wèn)題。樂(lè)觀鎖，大多是基于數(shù)據(jù)版本（Version）記錄機(jī)制實(shí)現(xiàn)：通過(guò)為數(shù)據(jù)庫(kù)表增加一個(gè)數(shù)字類型的version字段，當(dāng)讀取數(shù)據(jù)時(shí)，將version字段的值一同讀出，數(shù)據(jù)每更新一次，對(duì)此version值+1。當(dāng)我們提交更新的時(shí)候，判斷數(shù)據(jù)庫(kù)表對(duì)應(yīng)記錄的當(dāng)前版本信息與第一次取出來(lái)的version值進(jìn)行比對(duì)，如果數(shù)據(jù)庫(kù)表當(dāng)前版本號(hào)與第一次取出來(lái)的version值相等，則予以更新，否則認(rèn)為是過(guò)期數(shù)據(jù)，返回更新失敗。

鎖的粒度

MySQL定義了兩種鎖的粒度：表級(jí)、行級(jí)。

表鎖

由MySQL Server控制，分為讀鎖和寫(xiě)鎖。優(yōu)點(diǎn)是開(kāi)銷小，加鎖快；不會(huì)出現(xiàn)死鎖；缺點(diǎn)是鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低。表鎖適合查詢多、更新少的場(chǎng)景。

當(dāng)對(duì)表加了讀鎖，則會(huì)話只能讀取當(dāng)前被加鎖的表，其它會(huì)話仍然可以對(duì)表進(jìn)行讀取但不能寫(xiě)入。

當(dāng)對(duì)表加了寫(xiě)鎖，則會(huì)話可以讀取或?qū)懭氡患渔i的表，其它會(huì)話不能對(duì)加鎖的表進(jìn)行讀取或?qū)懭搿?/p>

行鎖

由存儲(chǔ)引擎實(shí)現(xiàn)，InnoDB支持，而MyISAM不支持。優(yōu)點(diǎn)是開(kāi)銷大，加鎖慢；會(huì)出現(xiàn)死鎖；缺點(diǎn)是鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。InnoDB引擎下默認(rèn)使用行級(jí)鎖。行級(jí)鎖適合按索引更新頻率高的場(chǎng)景。

InnoDB是MySQL最常用的存儲(chǔ)引擎，本文以此為角度講解MySQL的鎖機(jī)制。有關(guān)MySQL存儲(chǔ)引擎和有關(guān)B-Tree的知識(shí)，可以查看博客《徹底搞懂MySQL的索引》

行鎖的分類

1. 記錄鎖

記錄鎖（Record lock）在唯一索引列或主鍵列記錄上加鎖，且該值存在，否則加鎖類型為間隙鎖。例如SELECT a FROM t WHERE a = 12 FOR UPDATE，對(duì)值為12的索引進(jìn)行鎖定，防止其它事務(wù)插入、刪除、更新值為12的記錄行。

2. 間隙鎖

間隙鎖（Gap Lock），只有在可重復(fù)讀、串行化隔離級(jí)別才有，在索引記錄之間的間隙中加鎖，或者是在某一條索引之前或者之后加鎖，并不包括該索引本身。

例如：SELECT a FROM t WHERE a > 15 and a < 20 FOR UPDATE，且a存在的值為1、2、5、10、15、20，則將(15,20)的間隙鎖住。

間歇鎖的范圍：

1. 對(duì)主鍵或唯一索引當(dāng)前讀時(shí)，where條件全部精確命中(=或者in)，這種場(chǎng)景本身就不會(huì)出現(xiàn)幻讀，所以只會(huì)加記錄鎖。

2. 沒(méi)有索引的列當(dāng)前讀操作時(shí)，會(huì)加全表gap鎖，生產(chǎn)環(huán)境要注意。（所有主鍵x鎖，所有主鍵間隙gap鎖）

3. 非唯一索引列，如果where條件部分命中(>、<、like等)或者全未命中，則會(huì)加附近Gap間隙鎖。例如，某表數(shù)據(jù)如下，非唯一索引2,6,9,9,11,15。delete from table where another_id = 9要操作非唯一索引列9的數(shù)據(jù)，gap鎖將會(huì)鎖定的列是(6,11)，該區(qū)間內(nèi)無(wú)法插入數(shù)據(jù)。

4. 更多情況看文末的圖片總結(jié)。

在使用范圍條件檢索并鎖定記錄時(shí)，間歇鎖機(jī)制會(huì)阻塞符合條件范圍內(nèi)鍵值的并發(fā)插入，這往往會(huì)造成嚴(yán)重的鎖等待。因此，在實(shí)際應(yīng)用開(kāi)發(fā)中，尤其是并發(fā)插入比較多的應(yīng)用，要盡量?jī)?yōu)化業(yè)務(wù)邏輯，盡量使用相等條件來(lái)訪問(wèn)更新數(shù)據(jù)，避免使用范圍條件。

間隙鎖和間隙鎖之間是互不沖突的，間隙鎖唯一的作用就是為了防止其他事務(wù)的插入，在RR（可重復(fù)讀）級(jí)別下解決了幻讀的問(wèn)題。

例如id有3,4,5，間隙鎖鎖定id>3的數(shù)據(jù)，是指的4及后面的數(shù)字都會(huì)被鎖定。這樣的話加入新的數(shù)據(jù)id=6，就會(huì)被阻塞，從而避免了幻讀。

快照讀與當(dāng)前讀將在下一篇博客《一文理解MySQL的事務(wù)原則與事務(wù)隔離》進(jìn)行詳解

3. 臨鍵鎖

臨鍵鎖（Next-Key Lock）是記錄鎖和間隙鎖的合集。只有在可重復(fù)讀、串行化隔離級(jí)別才有。

例如一個(gè)索引有10,11,13,20這四個(gè)值。InnoDB可以根據(jù)需要使用記錄鎖將10，11，13，20四個(gè)索引鎖住，也可以使用間隙鎖將(-∞,10)，(10,11)，(11,13)，(13,20)，(20,+∞)五個(gè)范圍區(qū)間鎖住。而臨鍵鎖是記錄鎖和間隙鎖的合集。

4. 插入意向鎖

插入意向鎖（Insert Intention Locks），是一種特殊的間隙鎖，只有在執(zhí)行INSERT操作時(shí)才會(huì)加鎖，插入意向鎖之間不沖突，可以向一個(gè)間隙中同時(shí)插入多行數(shù)據(jù)，但插入意向鎖與間隙鎖是沖突的，當(dāng)有間隙鎖存在時(shí)，插入語(yǔ)句將被阻塞，正是這個(gè)特性解決了幻讀的問(wèn)題。

假設(shè)有一個(gè)記錄索引包含鍵值4和7，不同的事務(wù)分別插入5和6，每個(gè)事務(wù)都會(huì)產(chǎn)生一個(gè)加在4-7之間的插入意向鎖，獲取在插入行上的排它鎖，但是不會(huì)被互相鎖住，因?yàn)閿?shù)據(jù)行并不沖突。

意向鎖

innodb的意向鎖主要用戶多粒度的鎖并存的情況。比如事務(wù)A要在一個(gè)表上加S鎖，如果表中的一行已被事務(wù)B加了X鎖，那么該鎖的申請(qǐng)也應(yīng)被阻塞。如果表中的數(shù)據(jù)很多，逐行檢查鎖標(biāo)志的開(kāi)銷將很大，系統(tǒng)的性能將會(huì)受到影響。為了解決這個(gè)問(wèn)題，可以在表級(jí)上引入新的鎖類型來(lái)表示其所屬行的加鎖情況，這就引出了“意向鎖”的概念。

舉個(gè)例子，如果表中記錄1億，事務(wù)A把其中有幾條記錄上了行鎖了，這時(shí)事務(wù)B需要給這個(gè)表加表級(jí)鎖，如果沒(méi)有意向鎖的話，那就要去表中查找這一億條記錄是否上鎖了。如果存在意向鎖，那么假如事務(wù)A在更新一條記錄之前，先加意向鎖，再加X(jué)鎖，事務(wù)B先檢查該表上是否存在意向鎖，存在的意向鎖是否與自己準(zhǔn)備加的鎖沖突，如果有沖突，則等待直到事務(wù)A釋放，而無(wú)須逐條記錄去檢測(cè)。事務(wù)B更新表時(shí)，其實(shí)無(wú)須知道到底哪一行被鎖了，它只要知道反正有一行被鎖了就行了。

意向鎖的主要作用是處理行鎖和表鎖之間的矛盾，能夠顯示“某個(gè)事務(wù)正在某一行上持有了鎖，或者準(zhǔn)備去持有鎖”。

鎖的模式

共享鎖和排它鎖都是行級(jí)鎖。意向共享鎖和意向排他鎖是表級(jí)鎖。意向共享鎖和意向排他鎖都是系統(tǒng)自動(dòng)添加和自動(dòng)釋放的，整個(gè)過(guò)程無(wú)需人工干預(yù)。

1. 共享鎖

共享鎖（S鎖，Shared Lock）：又稱讀鎖，允許一個(gè)事務(wù)去讀數(shù)據(jù)集，阻止其他事務(wù)獲得該數(shù)據(jù)集的排他鎖。共享鎖與共享鎖可以同時(shí)使用。舉例：若事務(wù)T對(duì)數(shù)據(jù)對(duì)象A加上S鎖，則事務(wù)T可以讀A但不能修改A，其他事務(wù)只能再對(duì)A加S鎖，而不能加X(jué)鎖，直到T釋放A上的S鎖。這保證了其他事務(wù)可以讀A，但在T釋放A上的S鎖之前不能對(duì)A做任何修改。

2. 排他鎖

排他鎖（X鎖，Exclusive Lock）：又稱寫(xiě)鎖，允許獲取排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)獲得相同的數(shù)據(jù)集的共享鎖和排他鎖。排它鎖與排它鎖、共享鎖都不兼容。舉例：若事務(wù)T對(duì)數(shù)據(jù)對(duì)象A加上X鎖，事務(wù)T可以讀A也可以修改A，其他事務(wù)不能再對(duì)A加任何鎖，直到T釋放A上的鎖。

3. 意向共享鎖

意向共享鎖（IS鎖，Intention Shared Lock）：事務(wù)打算給數(shù)據(jù)行共享鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖。

4. 意向排他鎖

意向排他鎖（IX鎖，Intention Exclusive Lock）：事務(wù)打算給數(shù)據(jù)行加排他鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。

IS鎖和IX鎖的提出僅僅為了在之后加表級(jí)別的S鎖和X鎖時(shí)可以快速判斷表中的記錄是否被上鎖，以避免用遍歷的方式來(lái)查看表中有沒(méi)有上鎖的記錄，也就是說(shuō)其實(shí)IS鎖和IX鎖是兼容的，IX鎖和IX鎖是兼容的。

意向鎖之間不會(huì)發(fā)生沖突，但共享鎖、排它鎖、意向鎖之間會(huì)發(fā)生沖突，表級(jí)別各種鎖的兼容性如下表所示。

兼容性	X	IX	S	IS
X	不兼容	不兼容	不兼容	不兼容
IX	不兼容	兼容	不兼容	兼容
S	不兼容	不兼容	兼容	兼容
IS	不兼容	兼容	兼容	兼容

5. 自增鎖

AUTO-INC Locks，自增鎖，是一種特殊的表鎖。當(dāng)表有設(shè)置自增auto_increment列，在插入數(shù)據(jù)時(shí)會(huì)先獲取自增鎖，其它事務(wù)將會(huì)被阻塞插入操作，自增列+1后釋放鎖，如果事務(wù)回滾，自增值也不會(huì)回退，所以自增列并不一定是連續(xù)自增的。（MySQL 從 5.1.22 版本開(kāi)始，引入了一種可選的輕量級(jí)鎖（mutex）機(jī)制來(lái)代替AUTOINC鎖。見(jiàn)于參考文檔3）

6. 元數(shù)據(jù)鎖

元數(shù)據(jù)鎖（metadata lock），MySQL Server控制，表級(jí)鎖，是維護(hù)表元數(shù)據(jù)的數(shù)據(jù)一致性，保證在表上有活動(dòng)事務(wù)（顯式或隱式）的時(shí)候，不可以對(duì)元數(shù)據(jù)進(jìn)行寫(xiě)入操作。從MySQL5.5版本開(kāi)始引入了MDL鎖，來(lái)保護(hù)表的元數(shù)據(jù)信息，用于解決或者保證DDL操作與DML操作之間的一致性。

對(duì)于引入MDL，其主要解決了2個(gè)問(wèn)題：

1. 事務(wù)隔離問(wèn)題，比如在可重復(fù)隔離級(jí)別下，會(huì)話A在2次查詢期間，會(huì)話B對(duì)表結(jié)構(gòu)做了修改，兩次查詢結(jié)果就會(huì)不一致，無(wú)法滿足可重復(fù)讀的要求。

2. 數(shù)據(jù)復(fù)制的問(wèn)題，比如會(huì)話A執(zhí)行了多條更新語(yǔ)句期間，另外一個(gè)會(huì)話B做了表結(jié)構(gòu)變更并且先提交，就會(huì)導(dǎo)致slave在重做時(shí)，先重做alter，再重做update時(shí)就會(huì)出現(xiàn)復(fù)制錯(cuò)誤的現(xiàn)象。

每執(zhí)行一條DML、DDL語(yǔ)句時(shí)都會(huì)申請(qǐng)MDL鎖，DML操作需要MDL讀鎖，DDL操作需要MDL寫(xiě)鎖（MDL加鎖過(guò)程是系統(tǒng)自動(dòng)控制，無(wú)法直接干預(yù)，讀讀共享，讀寫(xiě)互斥，寫(xiě)寫(xiě)互斥），申請(qǐng)MDL鎖的操作會(huì)形成一個(gè)隊(duì)列，隊(duì)列中寫(xiě)鎖獲取優(yōu)先級(jí)高于讀鎖。

一旦出現(xiàn)MDL寫(xiě)鎖等待，不但當(dāng)前操作會(huì)被阻塞，同時(shí)還會(huì)阻塞后續(xù)該表的所有操作（不過(guò)在MySQL5.6的時(shí)候推出了online ddl機(jī)制，使得排隊(duì)的MDL寫(xiě)鎖進(jìn)行降級(jí)，防止對(duì)MDL讀鎖的阻塞）。

加鎖時(shí)機(jī)

• SELECT xxx 查詢語(yǔ)句正常情況下為快照讀，只加元數(shù)據(jù)讀鎖，直到事務(wù)結(jié)束。

• SELECT xxx LOCK IN SHARE MODE 語(yǔ)句為當(dāng)前讀，加S鎖和元數(shù)據(jù)讀鎖，直到事務(wù)結(jié)束。

• SELECT xxx FOR UPDATE 語(yǔ)句為當(dāng)前讀，加X(jué)鎖和元數(shù)據(jù)讀鎖，直到事務(wù)結(jié)束。

• DML語(yǔ)句（INSERT、DELETE、UPDATE）為當(dāng)前讀，加X(jué)鎖和元數(shù)據(jù)讀鎖，直到事務(wù)結(jié)束。

• DDL語(yǔ)句（ALTER、CREATE等）加元數(shù)據(jù)寫(xiě)鎖，且是隱式提交不能回滾，直到事務(wù)結(jié)束。

為什么DDL語(yǔ)句會(huì)隱式提交？因?yàn)镈DL是數(shù)據(jù)定義語(yǔ)言，在數(shù)據(jù)庫(kù)中承擔(dān)著創(chuàng)建、刪除和修改的重要的職責(zé)。一旦發(fā)生問(wèn)題，帶來(lái)的后果很可能是不可估量的。于是在每執(zhí)行完一次后就進(jìn)行提交，可以保證流暢性，數(shù)據(jù)不會(huì)發(fā)生阻塞，同時(shí)也會(huì)提高數(shù)據(jù)庫(kù)的整體性能。

線上踩坑舉例：由于DDL語(yǔ)句存在隱式提交，所以如果會(huì)話A開(kāi)始了事務(wù)，進(jìn)行了DML操作，然后進(jìn)行了DDL操作，然后會(huì)話A回滾事務(wù)。此時(shí)會(huì)話A回滾的事務(wù)是一個(gè)空事務(wù)，因?yàn)镈DL操作執(zhí)行的時(shí)候會(huì)進(jìn)行一次隱式提交

行鎖鎖住整表的場(chǎng)景

1. SQL語(yǔ)句沒(méi)有使用索引會(huì)把整張表鎖住。例如事務(wù)里進(jìn)行整表update；用到前綴like；字段沒(méi)有加索引；數(shù)據(jù)庫(kù)優(yōu)化將索引查詢轉(zhuǎn)全表掃描等等。

2. Mysql在5.6版本之前，直接修改表結(jié)構(gòu)的過(guò)程中會(huì)鎖表。

“查詢每個(gè)表索引，并使用最佳索引，除非優(yōu)化程序認(rèn)為使用表掃描更有效。一次使用掃描是基于最佳索引是否跨越了表的30％以上，但是固定百分比不再?zèng)Q定使用索引還是掃描。現(xiàn)在，優(yōu)化器更加復(fù)雜，并且根據(jù)附加因素（如表大小，行數(shù)和I / O塊大小）進(jìn)行估計(jì)。”見(jiàn)于參考文檔1。

實(shí)驗(yàn)操作下的加鎖情況分析

以下結(jié)論基于MySQL5.6，以InnoDB默認(rèn)的RR級(jí)別來(lái)實(shí)驗(yàn)，只用來(lái)方便理解本文提到的鎖機(jī)制。恐有紕漏，敬請(qǐng)諒解。

死鎖排查

INFORMATION_SCHEMA提供對(duì)數(shù)據(jù)庫(kù)元數(shù)據(jù)的訪問(wèn)、關(guān)于MySQL服務(wù)器的信息，如數(shù)據(jù)庫(kù)或表的名稱、列的數(shù)據(jù)類型或訪問(wèn)權(quán)限。其中有一個(gè)關(guān)于InnoDB數(shù)據(jù)庫(kù)引擎表的集合，里面有記錄數(shù)據(jù)庫(kù)事務(wù)和鎖的相關(guān)表。

MySQL有關(guān)事務(wù)和鎖的四條命令：

1. SELECT * FROM information_schema.INNODB_TRX;命令是用來(lái)查看當(dāng)前運(yùn)行的所有事務(wù)。

2. SELECT * FROM information_schema.INNODB_LOCKs;命令是用來(lái)查看當(dāng)前出現(xiàn)的鎖。

3. SELECT * FROM information_schema.INNODB_LOCK_waits;命令是用來(lái)查看鎖等待的對(duì)應(yīng)關(guān)系。

4. show engine innodb status \G;命令是用來(lái)獲取最近一次的死鎖信息。

在查詢結(jié)果中可以看到是否有表鎖等待或者死鎖。如果有死鎖發(fā)生，可以通過(guò)KILL trx_mysql_thread_id來(lái)殺掉當(dāng)前運(yùn)行的事務(wù)。

查詢事務(wù)與鎖的命令行

死鎖是并發(fā)系統(tǒng)中常見(jiàn)的問(wèn)題，同樣也會(huì)出現(xiàn)在數(shù)據(jù)庫(kù)MySQL的并發(fā)讀寫(xiě)請(qǐng)求場(chǎng)景中。當(dāng)兩個(gè)及以上的事務(wù)，雙方都在等待對(duì)方釋放已經(jīng)持有的鎖或因?yàn)榧渔i順序不一致造成循環(huán)等待鎖資源，就會(huì)出現(xiàn)“死鎖”。常見(jiàn)的報(bào)錯(cuò)信息為"Deadlock found when trying to get lock..."

MySQL死鎖問(wèn)題排查的常見(jiàn)思路：

1. 通過(guò)多終端模擬并發(fā)事務(wù)，復(fù)現(xiàn)死鎖。

2. 通過(guò)上面四條命令，查看事務(wù)與鎖的信息。

3. 通過(guò)explain可以查看執(zhí)行計(jì)劃。

發(fā)生死鎖異常后，通過(guò)開(kāi)啟InnoDB的監(jiān)控機(jī)制來(lái)獲取實(shí)時(shí)的死鎖信息，它會(huì)周期性（每隔 15 秒）打印 InnoDb 的運(yùn)行狀態(tài)到 mysqld服務(wù)的錯(cuò)誤日志文件中。

InnoDB的監(jiān)控較為重要的有標(biāo)準(zhǔn)監(jiān)控（Standard InnoDB Monitor）和鎖監(jiān)控（InnoDB Lock Monitor），通過(guò)對(duì)應(yīng)的系統(tǒng)參數(shù)可以將其開(kāi)啟。

set GLOBAL innodb_status_output=ON;開(kāi)啟標(biāo)準(zhǔn)監(jiān)控
set GLOBAL innodb_status_output_locks;開(kāi)啟所監(jiān)控

另外，MySQL 提供了一個(gè)系統(tǒng)參數(shù)innodb_print_all_deadlocks專門(mén)用于記錄死鎖日志，當(dāng)發(fā)生死鎖時(shí)，死鎖日志會(huì)記錄到 MySQL 的錯(cuò)誤日志文件中。

另外，MySQL 提供了一個(gè)系統(tǒng)參數(shù)innodb_print_all_deadlocks專門(mén)用于記錄死鎖日志，當(dāng)發(fā)生死鎖時(shí)，死鎖日志會(huì)記錄到 MySQL 的錯(cuò)誤日志文件中。

如何盡可能避免死鎖

1. 合理的設(shè)計(jì)索引，區(qū)分度高的列放到組合索引前面，使業(yè)務(wù)SQL盡可能通過(guò)索引定位更少的行，減少鎖競(jìng)爭(zhēng)。

2. 盡量按主鍵/索引去查找記錄，范圍查找增加了鎖沖突的可能性，也不要利用數(shù)據(jù)庫(kù)做一些額外額度計(jì)算工作。比如有的程序會(huì)用到select … where … order by rand();這樣的語(yǔ)句，類似這樣的語(yǔ)句用不到索引，因此將導(dǎo)致整個(gè)表的數(shù)據(jù)都被鎖住。

3. 大事務(wù)拆小。大事務(wù)更傾向于死鎖，如果業(yè)務(wù)允許，將大事務(wù)拆小。

4. 以固定的順序訪問(wèn)表和行。比如兩個(gè)更新數(shù)據(jù)的事務(wù)，事務(wù)A更新數(shù)據(jù)的順序?yàn)?，2;事務(wù)B更新數(shù)據(jù)的順序?yàn)?，1。這樣更可能會(huì)造成死鎖。

5. 降低隔離級(jí)別。如果業(yè)務(wù)允許，將隔離級(jí)別調(diào)低也是較好的選擇，比如將隔離級(jí)別從RR調(diào)整為RC，可以避免掉很多因?yàn)間ap鎖造成的死鎖。

參考文檔：

1. http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/where-optimization.com.coder114.cn.html

2. https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks

3. https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html