21 | 爲何我只改一行的語句，鎖這麼多？

在上一篇文章中，我和你介紹了間隙鎖和next-key lock的概念，可是並無說明加鎖規則。間隙鎖的概念理解起來確實有點兒難，尤爲在配合上行鎖之後，很容易在判斷是否會出現鎖等待的問題上犯錯。

因此今天，咱們就先從這個加鎖規則開始吧。

首先說明一下，這些加鎖規則我沒在別的地方看到過有相似的總結，之前我本身判斷的時候都是想着代碼裏面的實現來腦補的。此次爲了總結成不看代碼的同窗也能理解的規則，是我又從新刷了代碼臨時總結出來的。因此，這個規則有如下兩條前提說明：

1. MySQL後面的版本可能會改變加鎖策略，因此這個規則只限於截止到如今的最新版本，即5.x系列<=5.7.24，8.0系列 <=8.0.13。

2. 若是你們在驗證中有發現bad case的話，請提出來，我會再補充進這篇文章，使得一塊兒學習本專欄的全部同窗都能受益。

由於間隙鎖在可重複讀隔離級別下才有效，因此本篇文章接下來的描述，若沒有特殊說明，默認是可重複讀隔離級別。

我總結的加鎖規則裏面，包含了兩個「原則」、兩個「優化」和一個「bug」。

1. 原則1：加鎖的基本單位是next-key lock。但願你還記得，next-key lock是前開後閉區間。

2. 原則2：查找過程當中訪問到的對象纔會加鎖。

3. 優化1：索引上的等值查詢，給惟一索引加鎖的時候，next-key lock退化爲行鎖。

4. 優化2：索引上的等值查詢，向右遍歷時且最後一個值不知足等值條件的時候，next-key lock退化爲間隙鎖。

5. 一個bug：惟一索引上的範圍查詢會訪問到不知足條件的第一個值爲止。

我仍是以上篇文章的表t爲例，和你解釋一下這些規則。表t的建表語句和初始化語句以下。

CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
`d` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `c` (`c`)
) ENGINE=InnoDB;

insert into t values(0,0,0),(5,5,5),
(10,10,10),(15,15,15),(20,20,20),(25,25,25);

接下來的例子基本都是配合着圖片說明的，因此我建議你能夠對照着文稿看，有些例子可能會「毀三觀」，也建議你讀完文章後親手實踐一下。

案例一：等值查詢間隙鎖

第一個例子是關於等值條件操做間隙：

圖1 等值查詢的間隙鎖

因爲表t中沒有id=7的記錄，因此用咱們上面提到的加鎖規則判斷一下的話：

1. 根據原則1，加鎖單位是next-key lock，session A加鎖範圍就是(5,10]；

2. 同時根據優化2，這是一個等值查詢(id=7)，而id=10不知足查詢條件，next-key lock退化成間隙鎖，所以最終加鎖的範圍是(5,10)。

因此，session B要往這個間隙裏面插入id=8的記錄會被鎖住，可是session C修改id=10這行是能夠的。

案例二：非惟一索引等值鎖

第二個例子是關於覆蓋索引上的鎖：

圖2 只加在非惟一索引上的鎖

看到這個例子，你是否是有一種「該鎖的不鎖，不應鎖的亂鎖」的感受？咱們來分析一下吧。

這裏session A要給索引c上c=5的這一行加上讀鎖。

1. 根據原則1，加鎖單位是next-key lock，所以會給(0,5]加上next-key lock。

2. 要注意c是普通索引，所以僅訪問c=5這一條記錄是不能立刻停下來的，須要向右遍歷，查到c=10才放棄。根據原則2，訪問到的都要加鎖，所以要給(5,10]加next-key lock。

3. 可是同時這個符合優化2：等值判斷，向右遍歷，最後一個值不知足c=5這個等值條件，所以退化成間隙鎖(5,10)。

4. 根據原則2 ，只有訪問到的對象纔會加鎖，這個查詢使用覆蓋索引，並不須要訪問主鍵索引，因此主鍵索引上沒有加任何鎖，這就是爲何session B的update語句能夠執行完成。

但session C要插入一個(7,7,7)的記錄，就會被session A的間隙鎖(5,10)鎖住。

須要注意，在這個例子中，lock in share mode只鎖覆蓋索引，可是若是是for update就不同了。 執行 for update時，系統會認爲你接下來要更新數據，所以會順便給主鍵索引上知足條件的行加上行鎖。

這個例子說明，鎖是加在索引上的；同時，它給咱們的指導是，若是你要用lock in share mode來給行加讀鎖避免數據被更新的話，就必須得繞過覆蓋索引的優化，在查詢字段中加入索引中不存在的字段。好比，將session A的查詢語句改爲select d from t where c=5 lock in share mode。你能夠本身驗證一下效果。

案例三：主鍵索引範圍鎖

第三個例子是關於範圍查詢的。

舉例以前，你能夠先思考一下這個問題：對於咱們這個表t，下面這兩條查詢語句，加鎖範圍相同嗎？

mysql> select * from t where id=10 for update;
mysql> select * from t where id>=10 and id

你可能會想，id定義爲int類型，這兩個語句就是等價的吧？其實，它們並不徹底等價。

在邏輯上，這兩條查語句確定是等價的，可是它們的加鎖規則不太同樣。如今，咱們就讓session A執行第二個查詢語句，來看看加鎖效果。

圖3 主鍵索引上範圍查詢的鎖

如今咱們就用前面提到的加鎖規則，來分析一下session A 會加什麼鎖呢？

1. 開始執行的時候，要找到第一個id=10的行，所以本該是next-key lock(5,10]。 根據優化1， 主鍵id上的等值條件，退化成行鎖，只加了id=10這一行的行鎖。

2. 範圍查找就日後繼續找，找到id=15這一行停下來，所以須要加next-key lock(10,15]。

因此，session A這時候鎖的範圍就是主鍵索引上，行鎖id=10和next-key lock(10,15]。這樣，session B和session C的結果你就能理解了。

這裏你須要注意一點，首次session A定位查找id=10的行的時候，是當作等值查詢來判斷的，而向右掃描到id=15的時候，用的是範圍查詢判斷。

案例四：非惟一索引範圍鎖

接下來，咱們再看兩個範圍查詢加鎖的例子，你能夠對照着案例三來看。

須要注意的是，與案例三不一樣的是，案例四中查詢語句的where部分用的是字段c。

圖4 非惟一索引範圍鎖

此次session A用字段c來判斷，加鎖規則跟案例三惟一的不一樣是：在第一次用c=10定位記錄的時候，索引c上加了(5,10]這個next-key lock後，因爲索引c是非惟一索引，沒有優化規則，也就是說不會蛻變爲行鎖，所以最終sesion A加的鎖是，索引c上的(5,10] 和(10,15] 這兩個next-key lock。

因此從結果上來看，sesson B要插入（8,8,8)的這個insert語句時就被堵住了。

這裏須要掃描到c=15才中止掃描，是合理的，由於InnoDB要掃到c=15，才知道不須要繼續日後找了。

案例五：惟一索引範圍鎖bug

前面的四個案例，咱們已經用到了加鎖規則中的兩個原則和兩個優化，接下來再看一個關於加鎖規則中bug的案例。

圖5 惟一索引範圍鎖的bug

session A是一個範圍查詢，按照原則1的話，應該是索引id上只加(10,15]這個next-key lock，而且由於id是惟一鍵，因此循環判斷到id=15這一行就應該中止了。

可是實現上，InnoDB會往前掃描到第一個不知足條件的行爲止，也就是id=20。並且因爲這是個範圍掃描，所以索引id上的(15,20]這個next-key lock也會被鎖上。

因此你看到了，session B要更新id=20這一行，是會被鎖住的。一樣地，session C要插入id=16的一行，也會被鎖住。

照理說，這裏鎖住id=20這一行的行爲，實際上是沒有必要的。由於掃描到id=15，就能夠肯定不用日後再找了。但實現上仍是這麼作了，所以我認爲這是個bug。

我也曾找社區的專家討論過，官方bug系統上也有提到，可是並未被verified。因此，認爲這是bug這個事兒，也只能算個人一家之言，若是你有其餘看法的話，也歡迎你提出來。

案例六：非惟一索引上存在"等值"的例子

接下來的例子，是爲了更好地說明「間隙」這個概念。這裏，我給表t插入一條新記錄。

mysql> insert into t values(30,10,30);

新插入的這一行c=10，也就是說如今表裏有兩個c=10的行。那麼，這時候索引c上的間隙是什麼狀態了呢？你要知道，因爲非惟一索引上包含主鍵的值，因此是不可能存在「相同」的兩行的。

圖6 非惟一索引等值的例子

能夠看到，雖然有兩個c=10，可是它們的主鍵值id是不一樣的（分別是10和30），所以這兩個c=10的記錄之間，也是有間隙的。

圖中我畫出了索引c上的主鍵id。爲了跟間隙鎖的開區間形式進行區別，我用(c=10,id=30)這樣的形式，來表示索引上的一行。

如今，咱們來看一下案例六。

此次咱們用delete語句來驗證。注意，delete語句加鎖的邏輯，其實跟select ... for update 是相似的，也就是我在文章開始總結的兩個「原則」、兩個「優化」和一個「bug」。

圖7 delete 示例

這時，session A在遍歷的時候，先訪問第一個c=10的記錄。一樣地，根據原則1，這裏加的是(c=5,id=5)到(c=10,id=10)這個next-key lock。

而後，session A向右查找，直到碰到(c=15,id=15)這一行，循環才結束。根據優化2，這是一個等值查詢，向右查找到了不知足條件的行，因此會退化成(c=10,id=10) 到 (c=15,id=15)的間隙鎖。

也就是說，這個delete語句在索引c上的加鎖範圍，就是下圖中藍色區域覆蓋的部分。

圖8 delete加鎖效果示例

這個藍色區域左右兩邊都是虛線，表示開區間，即(c=5,id=5)和(c=15,id=15)這兩行上都沒有鎖。

案例七：limit 語句加鎖

例子6也有一個對照案例，場景以下所示：

圖9 limit 語句加鎖

這個例子裏，session A的delete語句加了 limit 2。你知道表t裏c=10的記錄其實只有兩條，所以加不加limit 2，刪除的效果都是同樣的，可是加鎖的效果卻不一樣。能夠看到，session B的insert語句執行經過了，跟案例六的結果不一樣。

這是由於，案例七裏的delete語句明確加了limit 2的限制，所以在遍歷到(c=10, id=30)這一行以後，知足條件的語句已經有兩條，循環就結束了。

所以，索引c上的加鎖範圍就變成了從（c=5,id=5)到（c=10,id=30)這個前開後閉區間，以下圖所示：

圖10 帶limit 2的加鎖效果

能夠看到，(c=10,id=30）以後的這個間隙並無在加鎖範圍裏，所以insert語句插入c=12是能夠執行成功的。

這個例子對咱們實踐的指導意義就是，在刪除數據的時候儘可能加limit。這樣不只能夠控制刪除數據的條數，讓操做更安全，還能夠減少加鎖的範圍。

案例八：一個死鎖的例子

前面的例子中，咱們在分析的時候，是按照next-key lock的邏輯來分析的，由於這樣分析比較方便。最後咱們再看一個案例，目的是說明：next-key lock其實是間隙鎖和行鎖加起來的結果。

你必定會疑惑，這個概念不是一開始就說了嗎？不要着急，咱們先來看下面這個例子：

圖11 案例八的操做序列

如今，咱們按時間順序來分析一下爲何是這樣的結果。

1. session A 啓動事務後執行查詢語句加lock in share mode，在索引c上加了next-key lock(5,10] 和間隙鎖(10,15)；

2. session B 的update語句也要在索引c上加next-key lock(5,10] ，進入鎖等待；

3. 而後session A要再插入(8,8,8)這一行，被session B的間隙鎖鎖住。因爲出現了死鎖，InnoDB讓session B回滾。

你可能會問，session B的next-key lock不是還沒申請成功嗎？

實際上是這樣的，session B的「加next-key lock(5,10] 」操做，實際上分紅了兩步，先是加(5,10)的間隙鎖，加鎖成功；而後加c=10的行鎖，這時候才被鎖住的。

也就是說，咱們在分析加鎖規則的時候能夠用next-key lock來分析。可是要知道，具體執行的時候，是要分紅間隙鎖和行鎖兩段來執行的。

小結

這裏我再次說明一下，咱們上面的全部案例都是在可重複讀隔離級別(repeatable-read)下驗證的。同時，可重複讀隔離級別遵照兩階段鎖協議，全部加鎖的資源，都是在事務提交或者回滾的時候才釋放的。

在最後的案例中，你能夠清楚地知道next-key lock其實是由間隙鎖加行鎖實現的。若是切換到讀提交隔離級別(read-committed)的話，就好理解了，過程當中去掉間隙鎖的部分，也就是隻剩下行鎖的部分。

其實讀提交隔離級別在外鍵場景下仍是有間隙鎖，相對比較複雜，咱們今天先不展開。

另外，在讀提交隔離級別下還有一個優化，即：語句執行過程當中加上的行鎖，在語句執行完成後，就要把「不知足條件的行」上的行鎖直接釋放了，不須要等到事務提交。

也就是說，讀提交隔離級別下，鎖的範圍更小，鎖的時間更短，這也是很多業務都默認使用讀提交隔離級別的緣由。

不過，我但願你學過今天的課程之後，能夠對next-key lock的概念有更清晰的認識，而且會用加鎖規則去判斷語句的加鎖範圍。

在業務須要使用可重複讀隔離級別的時候，可以更細緻地設計操做數據庫的語句，解決幻讀問題的同時，最大限度地提高系統並行處理事務的能力。

通過這篇文章的介紹，你再看一下上一篇文章最後的思考題，再來嘗試分析一次。

我把題目從新描述和簡化一下：仍是咱們在文章開頭初始化的表t，裏面有6條記錄，圖12的語句序列中，爲何session B的insert操做，會被鎖住呢？

圖12 鎖分析思考題

另外，若是你有興趣多作一些實驗的話，能夠設計好語句序列，在執行以前先本身分析一下，而後實際地驗證結果是否跟你的分析一致。

對於那些你本身沒法解釋的結果，能夠發到評論區裏，後面我爭取挑一些有趣的案例在文章中分析。

你能夠把你關於思考題的分析寫在留言區，也能夠分享你本身設計的鎖驗證方案，我會在下一篇文章的末尾選取有趣的評論跟你們分享。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一塊兒閱讀。

上期問題時間

上期的問題，我在本期繼續做爲了課後思考題，因此會在下篇文章再一塊兒公佈「答案」。

這裏，我展開回答一下評論區幾位同窗的問題。

• @令狐少俠 說，之前一直認爲間隙鎖只在二級索引上有。如今你知道了，有間隙的地方就可能有間隙鎖。
• @浪裏白條 同窗問，若是是varchar類型，加鎖規則是什麼樣的。
  回答：實際上在判斷間隙的時候，varchar和int是同樣的，排好序之後，相鄰兩個值之間就有間隙。
• 有幾位同窗提到說，上一篇文章本身驗證的結果跟案例一不一樣，就是在session A執行完這兩個語句：

begin;
select * from t where d=5 for update; /*Q1*/

之後，session B 的update 和session C的insert 都會被堵住。這是否是跟文章的結論矛盾？

其實不是的，這個例子用的是反證假設，就是假設不堵住，會出現問題；而後，推導出session A須要鎖整個表全部的行和全部間隙。