在上一篇文章中，我和你介紹了間隙鎖和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);
 

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

案例一：等值查詢間隙鎖

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

由於表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這行是可以的。

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

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

看到這個例子，你是不是有一種“該鎖的不鎖，不該鎖的亂鎖”的感覺？我們來分析一下吧。

這裡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<11 for update;

你可能會想，id定義為int型別，這兩個語句就是等價的吧？其實，它們並不完全等價。

在邏輯上，這兩條查語句肯定是等價的，但是它們的加鎖規則不太一樣。現在，我們就讓session A執行第二個查詢語句，來看看加鎖效果。

現在我們就用前面提到的加鎖規則，來分析一下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。

這次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的案例。

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上的間隙是什麼狀態了呢？你要知道，由於非唯一索引上包含主鍵的值，所以是不可能存在“相同”的兩行的。

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

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

現在，我們來看一下案例六。

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

這時，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上的加鎖範圍，就是下圖中藍色區域覆蓋的部分。

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

案例七：limit 語句加鎖

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

這個例子裡，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)這個前開後閉區間，如下圖所示：

可以看到，(c=10,id=30）之後的這個間隙並沒有在加鎖範圍裡，因此insert語句插入c=12是可以執行成功的。

這個例子對我們實踐的指導意義就是，在刪除資料的時候儘量加limit。這樣不僅可以控制刪除資料的條數，讓操作更安全，還可以減小加鎖的範圍。

案例八：一個死鎖的例子

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

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

現在，我們按時間順序來分析一下為什麼是這樣的結果。

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操作，會被鎖住呢？

另外，如果你有興趣多做一些實驗的話，可以設計好語句序列，在執行之前先自己分析一下，然後實際地驗證結果是否跟你的分析一致。

對於那些你自己無法解釋的結果，可以發到評論區裡，後面我爭取挑一些有趣的案例在文章中分析。

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