保姆級教程！2 萬字 + 30 張圖搞懂 MySQL 是怎麼加行級鎖的？

文章內容比較長，大家可以耐心看下去，看完之後你會有一種突然被頓悟的感覺，因為我自己寫完這篇文章後，自己也被自己頓悟了。

正文

是不是很多人都對 MySQL 加行級鎖的規則搞的迷迷糊糊，對記錄一會加的是 next-key 鎖，一會加是間隙鎖，一會又是記錄鎖。

坦白說，確實還挺複雜的，但是好在我找點了點規律，也知道如何如何用命令分析加了什麼型別的行級鎖。

為了說清楚這三件事情：

1、MySQL 是怎麼加行級鎖的？有什麼規則？

2、為什麼 MySQL 要這麼加行級鎖？

3、如何用命令分析加了什麼行級鎖？

所以我重寫了這篇文章。

目錄結構如下：

什麼 SQL 語句會加行級鎖？

InnoDB 引擎是支援行級鎖的，而 MyISAM 引擎並不支援行級鎖，所以後面的內容都是基於 InnoDB 引擎 的。

所以，在說 MySQL 是怎麼加行級鎖的時候，其實是在說 InnoDB 引擎是怎麼加行級鎖的。

普通的 select 語句是不會對記錄加鎖的，因為它屬於快照讀，是透過  MVCC（多版本併發控制）實現的。

如果要在查詢時對記錄加行級鎖，可以使用下面這兩個方式，這兩種查詢會加鎖的語句稱為鎖定讀。

//對讀取的記錄加共享鎖(S型鎖)
select ... lock in share mode;

//對讀取的記錄加獨佔鎖(X型鎖)
select ... for update;

上面這兩條語句必須在一個事務中，因為當事務提交了，鎖就會被釋放，所以在使用這兩條語句的時候，要加上 begin 或者 start transaction 開啟事務的語句。

**除了上面這兩條鎖定讀語句會加行級鎖之外，update 和 delete 操作都會加行級鎖，且鎖的型別都是獨佔鎖(X型鎖)**。

//對操作的記錄加獨佔鎖(X型鎖)
updaet table .... where id = 1;

//對操作的記錄加獨佔鎖(X型鎖)
delete from table where id = 1;

共享鎖（S鎖）滿足讀讀共享，讀寫互斥。獨佔鎖（X鎖）滿足寫寫互斥、讀寫互斥。

行級鎖有哪些種類？

不同隔離級別下，行級鎖的種類是不同的。

在讀已提交隔離級別下，行級鎖的種類只有記錄鎖，也就是僅僅把一條記錄鎖上。

在可重複讀隔離級別下，行級鎖的種類除了有記錄鎖，還有間隙鎖（目的是為了避免幻讀），所以行級鎖的種類主要有三類：

• Record Lock，記錄鎖，也就是僅僅把一條記錄鎖上；
• Gap Lock，間隙鎖，鎖定一個範圍，但是不包含記錄本身；
• Next-Key Lock：Record Lock + Gap Lock 的組合，鎖定一個範圍，並且鎖定記錄本身。

接下來，分別介紹這三種行級鎖。

Record Lock

Record Lock 稱為記錄鎖，鎖住的是一條記錄。而且記錄鎖是有 S 鎖和 X 鎖之分的：

• 當一個事務對一條記錄加了 S 型記錄鎖後，其他事務也可以繼續對該記錄加 S 型記錄鎖（S 型與 S 鎖相容），但是不可以對該記錄加 X 型記錄鎖（S 型與 X 鎖不相容）;
• 當一個事務對一條記錄加了 X 型記錄鎖後，其他事務既不可以對該記錄加 S 型記錄鎖（S 型與 X 鎖不相容），也不可以對該記錄加 X 型記錄鎖（X 型與 X 鎖不相容）。

舉個例子，當一個事務執行了下面這條語句：

mysql > begin;
mysql > select * from t_test where id = 1 for update;

事務會對錶中主鍵 id = 1 的這條記錄加上 X 型的記錄鎖，如果這時候其他事務對這條記錄進行刪除或者更新操作，那麼這些操作都會被阻塞。注意，其他事務插入一條 id = 1 的新記錄並不會被阻塞，而是會報主鍵衝突的錯誤，這是因為主鍵有唯一性的約束。

當事務執行 commit 後，事務過程中生成的鎖都會被釋放。

Gap Lock

Gap Lock 稱為間隙鎖，只存在於可重複讀隔離級別，目的是為了解決可重複讀隔離級別下幻讀的現象。

假設，表中有一個範圍 id 為（3，5）間隙鎖，那麼其他事務就無法插入 id = 4 這條記錄了，這樣就有效的防止幻讀現象的發生。

間隙鎖雖然存在 X 型間隙鎖和 S 型間隙鎖，但是並沒有什麼區別，間隙鎖之間是相容的，即兩個事務可以同時持有包含共同間隙範圍的間隙鎖，並不存在互斥關係，因為間隙鎖的目的是防止插入幻影記錄而提出的。

Next-Key Lock

Next-Key Lock 稱為臨鍵鎖，是 Record Lock + Gap Lock 的組合，鎖定一個範圍，並且鎖定記錄本身。

假設，表中有一個範圍 id 為（3，5] 的 next-key lock，那麼其他事務即不能插入 id = 4 記錄，也不能修改和刪除 id = 5 這條記錄。

所以，next-key lock 即能保護該記錄，又能阻止其他事務將新記錄插入到被保護記錄前面的間隙中。

next-key lock 是包含間隙鎖+記錄鎖的，如果一個事務獲取了 X 型的 next-key lock，那麼另外一個事務在獲取相同範圍的 X 型的 next-key lock 時，是會被阻塞的。

比如，一個事務持有了範圍為 (1, 10] 的 X 型的 next-key lock，那麼另外一個事務在獲取相同範圍的 X 型的 next-key lock 時，就會被阻塞。

雖然相同範圍的間隙鎖是多個事務相互相容的，但對於記錄鎖，我們是要考慮 X 型與 S 型關係，X 型的記錄鎖與 X 型的記錄鎖是衝突的。

MySQL 是怎麼加行級鎖的？

行級鎖加鎖規則比較複雜，不同的場景，加鎖的形式是不同的。

加鎖的物件是索引，加鎖的基本單位是 next-key lock，它是由記錄鎖和間隙鎖組合而成的，next-key lock 是前開後閉區間，而間隙鎖是前開後開區間。

但是，next-key lock 在一些場景下會退化成記錄鎖或間隙鎖。

那到底是什麼場景呢？總結一句，在能使用記錄鎖或者間隙鎖就能避免幻讀現象的場景下， next-key lock  就會退化成退化成記錄鎖或間隙鎖。

這次會以下面這個表結構來進行實驗說明：

CREATE TABLE `user` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
  `age` int NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index_age` (`age`) USING BTREE
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

其中，id 是主鍵索引（唯一索引），age 是普通索引（非唯一索引），name 是普通的列。

表中的有這些行記錄：

這次實驗環境的 MySQL 版本是 8.0.26，隔離級別是「可重複讀」。

不同版本的加鎖規則可能是不同的，但是大體上是相同的。

唯一索引等值查詢

當我們用唯一索引進行等值查詢的時候，查詢的記錄存不存在，加鎖的規則也會不同：

• 當查詢的記錄是「存在」的，在索引樹上定位到這一條記錄後，將該記錄的索引中的 next-key lock 會退化成「記錄鎖」。
• 當查詢的記錄是「不存在」的，在索引樹找到第一條大於該查詢記錄的記錄後，將該記錄的索引中的 next-key lock 會退化成「間隙鎖」。

接下里用兩個案例來說明。

1、記錄存在的情況

假設事務 A 執行了這條等值查詢語句，查詢的記錄是「存在」於表中的。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where id = 1 for update;
+----+--------+-----+
| id | name   | age |
+----+--------+-----+
|  1 | 路飛   |  19 |
+----+--------+-----+
1 row in set (0.02 sec)

那麼，事務 A 會為 id 為 1 的這條記錄就會加上 X 型的記錄鎖。

接下來，如果有其他事務，對 id 為 1 的記錄進行更新或者刪除操作的話，這些操作都會被阻塞，因為更新或者刪除操作也會對記錄加 X 型的記錄鎖，而 X 鎖和 X 鎖之間是互斥關係。

比如，下面這個例子：

因為事務 A 對 id = 1的記錄加了 X 型的記錄鎖，所以事務 B 在修改 id=1 的記錄時會被阻塞，事務 C 在刪除 id=1 的記錄時也會被阻塞。

有什麼命令可以分析加了什麼鎖？

我們可以透過 select * from performance_schema.data_locks\G; 這條語句，檢視事務執行 SQL 過程中加了什麼鎖。

我們以前面的事務 A 作為例子，分析下下它加了什麼鎖。

從上圖可以看到，共加了兩個鎖，分別是：

• 表鎖：X 型別的意向鎖；
• 行鎖：X 型別的記錄鎖；

這裡我們重點關注行級鎖，圖中 LOCK_TYPE 中的 RECORD 表示行級鎖，而不是記錄鎖的意思。

透過 LOCK_MODE 可以確認是 next-key 鎖，還是間隙鎖，還是記錄鎖：

• 如果 LOCK_MODE 為 X，說明是 next-key 鎖；
• 如果 LOCK_MODE 為 X, REC_NOT_GAP，說明是記錄鎖；
• 如果 LOCK_MODE 為 X, GAP，說明是間隙鎖；

因此，此時事務 A 在 id = 1 記錄的主鍵索引上加的是記錄鎖，鎖住的範圍是 id 為 1 的這條記錄。這樣其他事務就無法對 id 為 1 的這條記錄進行更新和刪除操作了。

從這裡我們也可以得知，加鎖的物件是針對索引，因為這裡查詢語句掃描的 B+ 樹是聚簇索引樹，即主鍵索引樹，所以是對主鍵索引加鎖。將對應記錄的主鍵索引加 記錄鎖後，就意味著其他事務無法對該記錄進行更新和刪除操作了。

為什麼唯一索引等值查詢並且查詢記錄存在的場景下，該記錄的索引中的 next-key lock 會退化成記錄鎖？

原因就是在唯一索引等值查詢並且查詢記錄存在的場景下，僅靠記錄鎖也能避免幻讀的問題。

幻讀的定義就是，當一個事務前後兩次查詢的結果集，不相同時，就認為發生幻讀。所以，要避免幻讀就是避免結果集某一條記錄被其他事務刪除，或者有其他事務插入了一條新記錄，這樣前後兩次查詢的結果集就不會出現不相同的情況。

• 由於主鍵具有唯一性，所以其他事務插入 id = 1 的時候，會因為主鍵衝突，導致無法插入 id = 1 的新記錄。這樣事務 A 在多次查詢  id = 1 的記錄的時候，不會出現前後兩次查詢的結果集不同，也就避免了幻讀的問題。

• 由於對 id = 1 加了記錄鎖，其他事務無法刪除該記錄，這樣事務 A 在多次查詢  id = 1 的記錄的時候，不會出現前後兩次查詢的結果集不同，也就避免了幻讀的問題。

2、記錄不存在的情況

假設事務 A 執行了這條等值查詢語句，查詢的記錄是「不存在」於表中的。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where id = 2 for update;
Empty set (0.03 sec)

接下來，透過 select * from performance_schema.data_locks\G; 這條語句，檢視事務執行 SQL 過程中加了什麼鎖。

從上圖可以看到，共加了兩個鎖，分別是：

• 表鎖：X 型別的意向鎖；
• 行鎖：X 型別的間隙鎖；

因此，此時事務 A 在 id = 5 記錄的主鍵索引上加的是間隙鎖，鎖住的範圍是 (1, 5)。

接下來，如果有其他事務插入 id 值為 2、3、4 這一些記錄的話，這些插入語句都會發生阻塞。

注意，如果其他事務插入的 id = 1 或者 id = 5 的記錄話，並不會發生阻塞，而是報主鍵衝突的錯誤，因為表中已經存在 id = 1 和 id = 5 的記錄了。

比如，下面這個例子：

因為事務 A 在 id = 5 記錄的主鍵索引上加了範圍為 (1, 5) 的 X 型間隙鎖，所以事務 B 在插入一條 id 為 3 的記錄時會被阻塞住，即無法插入 id = 3 的記錄。

間隙鎖的範圍(1, 5) ，是怎麼確定的？

根據我的經驗，如果 LOCK_MODE 是 next-key 鎖或者間隙鎖，那麼 LOCK_DATA 就表示鎖的範圍「右邊界」，此次的事務 A 的 LOCK_DATA 是 5。

然後鎖範圍的「左邊界」是表中 id 為 5 的上一條記錄的 id 值，即 1。

因此，間隙鎖的範圍(1, 5)。

為什麼唯一索引等值查詢並且查詢記錄「不存在」的場景下，在索引樹找到第一條大於該查詢記錄的記錄後，要將該記錄的索引中的 next-key lock 會退化成「間隙鎖」？

原因就是在唯一索引等值查詢並且查詢記錄不存在的場景下，僅靠間隙鎖就能避免幻讀的問題。

• 為什麼 id = 5 記錄上的主鍵索引的鎖不可以是 next-key lock？如果是 next-key lock，就意味著其他事務無法刪除 id = 5 這條記錄，但是這次的案例是查詢 id = 2 的記錄，只要保證前後兩次查詢 id = 2 的結果集相同，就能避免幻讀的問題了，所以即使 id =5 被刪除，也不會有什麼影響，那就沒必須加 next-key lock，因此只需要在 id = 5 加間隙鎖，避免其他事務插入 id = 2 的新記錄就行了。
• 為什麼不可以針對不存在的記錄加記錄鎖？鎖是加在索引上的，而這個場景下查詢的記錄是不存在的，自然就沒辦法鎖住這條不存在的記錄。

唯一索引範圍查詢

範圍查詢和等值查詢的加鎖規則是不同的。

當唯一索引進行範圍查詢時，會對每一個掃描到的索引加 next-key 鎖，然後如果遇到下面這些情況，會退化成記錄鎖或者間隙鎖：

• 情況一：針對「大於等於」的範圍查詢，因為存在等值查詢的條件，那麼如果等值查詢的記錄是存在於表中，那麼該記錄的索引中的 next-key 鎖會退化成記錄鎖。
• 情況二：針對「小於或者小於等於」的範圍查詢，要看條件值的記錄是否存在於表中：
• 當條件值的記錄不在表中，那麼不管是「小於」還是「小於等於」條件的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄的索引的 next-key 鎖會退化成間隙鎖，其他掃描到的記錄，都是在這些記錄的索引上加 next-key 鎖。
• 當條件值的記錄在表中，如果是「小於」條件的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄的索引的 next-key 鎖會退化成間隙鎖，其他掃描到的記錄，都是在這些記錄的索引上加 next-key 鎖；如果「小於等於」條件的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄的索引 next-key 鎖不會退化成間隙鎖。其他掃描到的記錄，都是在這些記錄的索引上加 next-key 鎖。

接下來，透過幾個實驗，才驗證我上面說的結論。

1、針對「大於或者大於等於」的範圍查詢

實驗一：針對「大於」的範圍查詢的情況。

假設事務 A 執行了這條範圍查詢語句：

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where id > 15 for update;
+----+-----------+-----+
| id | name      | age |
+----+-----------+-----+
| 20 | 香克斯    |  39 |
+----+-----------+-----+
1 row in set (0.01 sec)

事務 A 加鎖變化過程如下：

1. 最開始要找的第一行是 id = 20，由於查詢該記錄不是一個等值查詢（不是大於等於條件查詢），所以對該主鍵索引加的是範圍為  (15, 20] 的 next-key 鎖；
2. 由於是範圍查詢，就會繼續往後找存在的記錄，雖然我們看見表中最後一條記錄是 id = 20 的記錄，但是實際在 Innodb 儲存引擎中，會用一個特殊的記錄來標識最後一條記錄，該特殊的記錄的名字叫 supremum pseudo-record ，所以掃描第二行的時候，也就掃描到了這個特殊記錄的時候，會對該主鍵索引加的是範圍為  (20, +∞] 的 next-key 鎖。
3. 停止掃描。

可以得知，事務 A 在主鍵索引上加了兩個 X 型 的 next-key 鎖：

• 在 id = 20 這條記錄的主鍵索引上，加了範圍為 (15, 20] 的 next-key 鎖，意味著其他事務即無法更新或者刪除 id = 20 的記錄，同時無法插入 id 值為 16、17、18、19 的這一些新記錄。
• 在特殊記錄（ supremum pseudo-record）的主鍵索引上，加了範圍為 (20, +∞] 的 next-key 鎖，意味著其他事務無法插入 id 值大於 20 的這一些新記錄。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

從上圖中的分析中，也可以得到事務 A 在主鍵索引上加了兩個 X 型 的next-key 鎖：

• 在 id = 20 這條記錄的主鍵索引上，加了範圍為 (15, 20] 的 next-key 鎖，意味著其他事務即無法更新或者刪除 id = 20 的記錄，同時無法插入 id 值為 16、17、18、19 的這一些新記錄。
• 在特殊記錄（ supremum pseudo-record）的主鍵索引上，加了範圍為 (20, +∞] 的 next-key 鎖，意味著其他事務無法插入 id 值大於 20 的這一些新記錄。

實驗二：針對「大於等於」的範圍查詢的情況。

假設事務 A 執行了這條範圍查詢語句：

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where id >= 15 for update;
+----+-----------+-----+
| id | name      | age |
+----+-----------+-----+
| 15 | 烏索普    |  20 |
| 20 | 香克斯    |  39 |
+----+-----------+-----+
2 rows in set (0.00 sec)

事務 A 加鎖變化過程如下：

1. 最開始要找的第一行是 id = 15，由於查詢該記錄是一個等值查詢（等於 15），所以該主鍵索引的 next-key 鎖會退化成記錄鎖，也就是僅鎖住 id = 15 這一行記錄。
2. 由於是範圍查詢，就會繼續往後找存在的記錄，掃描到的第二行是 id = 20，於是對該主鍵索引加的是範圍為  (15, 20] 的 next-key 鎖；
3. 接著掃描到第三行的時候，掃描到了特殊記錄（ supremum pseudo-record），於是對該主鍵索引加的是範圍為  (20, +∞] 的 next-key 鎖。
4. 停止掃描。

可以得知，事務 A 在主鍵索引上加了三個 X 型 的鎖，分別是：

• 在 id = 15 這條記錄的主鍵索引上，加了記錄鎖，範圍是 id = 15 這一行記錄；意味著其他事務無法更新或者刪除 id = 15 的這一條記錄；
• 在 id = 20 這條記錄的主鍵索引上，加了 next-key 鎖，範圍是  (15, 20] 。意味著其他事務即無法更新或者刪除 id = 20 的記錄，同時無法插入 id 值為 16、17、18、19 的這一些新記錄。
• 在特殊記錄（ supremum pseudo-record）的主鍵索引上，加了 next-key 鎖，範圍是  (20, +∞] 。意味著其他事務無法插入 id 值大於 20 的這一些新記錄。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

透過前面這個實驗，我們證明了：

• 針對「大於等於」條件的唯一索引範圍查詢的情況下， 如果條件值的記錄存在於表中，那麼由於查詢該條件值的記錄是包含一個等值查詢的操作，所以該記錄的索引中的 next-key 鎖會退化成記錄鎖。

2、針對「小於或者小於等於」的範圍查詢

實驗一：針對「小於」的範圍查詢時，查詢條件值的記錄「不存在」表中的情況。

假設事務 A 執行了這條範圍查詢語句，注意查詢條件值的記錄（id 為 6）並不存在於表中。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where id < 6 for update;
+----+--------+-----+
| id | name   | age |
+----+--------+-----+
|  1 | 路飛   |  19 |
|  5 | 索隆   |  21 |
+----+--------+-----+
3 rows in set (0.00 sec)

事務 A 加鎖變化過程如下：

1. 最開始要找的第一行是 id = 1，於是對該主鍵索引加的是範圍為  (-∞, 1] 的 next-key 鎖；
2. 由於是範圍查詢，就會繼續往後找存在的記錄，掃描到的第二行是 id = 5，所以對該主鍵索引加的是範圍為  (1, 5] 的 next-key 鎖；
3. 由於掃描到的第二行記錄（id = 5），滿足 id < 6 條件，而且也沒有達到終止掃描的條件，接著會繼續掃描。
4. 掃描到的第三行是 id = 10，該記錄不滿足 id < 6 條件的記錄，所以 id = 10 這一行記錄的鎖會退化成間隙鎖，於是對該主鍵索引加的是範圍為  (5, 10) 的間隙鎖。
5. 由於掃描到的第三行記錄（id = 10），不滿足 id < 6 條件，達到了終止掃描的條件，於是停止掃描。

從上面的分析中，可以得知事務 A 在主鍵索引上加了三個 X 型的鎖：

• 在 id = 1 這條記錄的主鍵索引上，加了範圍為  (-∞, 1] 的 next-key 鎖，意味著其他事務即無法更新或者刪除 id = 1 的這一條記錄，同時也無法插入 id 小於 1 的這一些新記錄。
• 在 id = 5 這條記錄的主鍵索引上，加了範圍為  (1, 5] 的 next-key 鎖，意味著其他事務即無法更新或者刪除 id = 5 的這一條記錄，同時也無法插入 id 值為 2、3、4 的這一些新記錄。
• 在 id = 10 這條記錄的主鍵索引上，加了範圍為 (5, 10) 的間隙鎖，意味著其他事務無法插入 id 值為 6、7、8、9 的這一些新記錄。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

從上圖中的分析中，也可以得知事務 A 在主鍵索引加的三個鎖，就是我們前面分析出那三個鎖。

雖然這次範圍查詢的條件是「小於」，但是查詢條件值的記錄不存在於表中（ id 為 6 的記錄不在表中），所以如果事務 A 的範圍查詢的條件改成 <= 6 的話，加的鎖還是和範圍查詢條件為 < 6 是一樣的。大家自己也驗證下這個結論。

因此，針對「小於或者小於等於」的唯一索引範圍查詢，如果條件值的記錄不在表中，那麼不管是「小於」還是「小於等於」的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄中索引的 next-key 鎖會退化成間隙鎖，其他掃描的記錄，則是在這些記錄的索引上加 next-key 鎖。

實驗二：針對「小於等於」的範圍查詢時，查詢條件值的記錄「存在」表中的情況。

假設事務 A 執行了這條範圍查詢語句，注意查詢條件值的記錄（id 為 5）存在於表中。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where id <= 5 for update;
+----+--------+-----+
| id | name   | age |
+----+--------+-----+
|  1 | 路飛   |  19 |
|  5 | 索隆   |  21 |
+----+--------+-----+
2 rows in set (0.00 sec)

事務 A 加鎖變化過程如下：

1. 最開始要找的第一行是 id = 1，於是對該記錄加的是範圍為  (-∞, 1] 的 next-key 鎖；
2. 由於是範圍查詢，就會繼續往後找存在的記錄，掃描到的第二行是 id = 5，於是對該記錄加的是範圍為  (1, 5] 的 next-key 鎖。
3. 由於主鍵索引具有唯一性，不會存在兩個 id = 5 的記錄，所以不會再繼續掃描，於是停止掃描。

從上面的分析中，可以得到事務 A 在主鍵索引上加了 2 個 X 型的鎖：

• 在 id = 1 這條記錄的主鍵索引上，加了範圍為  (-∞, 1] 的 next-key 鎖。意味著其他事務即無法更新或者刪除 id = 1 的這一條記錄，同時也無法插入 id 小於 1 的這一些新記錄。
• 在 id = 5 這條記錄的主鍵索引上，加了範圍為  (1, 5] 的 next-key 鎖。意味著其他事務即無法更新或者刪除 id = 5 的這一條記錄，同時也無法插入 id 值為 2、3、4 的這一些新記錄。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

從上圖中的分析中，可以得到事務 A 在主鍵索引上加了兩個 X 型 next-key 鎖，分別是：

• 在 id = 1 這條記錄的主鍵索引上，加了範圍為  (-∞, 1] 的 next-key 鎖；
• 在 id = 5 這條記錄的主鍵索引上，加了範圍為(1, 5 ] 的 next-key 鎖。

實驗三：再來看針對「小於」的範圍查詢時，查詢條件值的記錄「存在」表中的情況。

如果事務 A 的查詢語句是小於的範圍查詢，且查詢條件值的記錄（id 為 5）存在於表中。

select * from user where id < 5 for update;

事務 A 加鎖變化過程如下：

1. 最開始要找的第一行是 id = 1，於是對該記錄加的是範圍為  (-∞, 1] 的 next-key 鎖；
2. 由於是範圍查詢，就會繼續往後找存在的記錄，掃描到的第二行是 id = 5，該記錄是第一條不滿足 id < 5 條件的記錄，於是**該記錄的鎖會退化為間隙鎖，鎖範圍是 (1,5)**。
3. 由於找到了第一條不滿足 id < 5 條件的記錄，於是停止掃描。

可以得知，此時事務 A 在主鍵索引上加了兩種 X 型鎖：

• 在 id = 1 這條記錄的主鍵索引上，加了範圍為  (-∞, 1] 的 next-key 鎖，意味著其他事務即無法更新或者刪除 id = 1 的這一條記錄，同時也無法插入 id 小於 1 的這一些新記錄。

• 在 id = 5 這條記錄的主鍵索引上，加了範圍為 (1,5) 的間隙鎖，意味著其他事務無法插入 id 值為 2、3、4 的這一些新記錄。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

從上圖中的分析中，可以得到事務 A 在主鍵索引上加了 X 型的範圍為  (-∞, 1] 的 next-key 鎖，和 X 型的範圍為 (1, 5) 的間隙鎖。

因此，透過前面這三個實驗，可以得知。

在針對「小於或者小於等於」的唯一索引（主鍵索引）範圍查詢時，存在這兩種情況會將索引的 next-key 鎖會退化成間隙鎖的：

• 當條件值的記錄「不在」表中時，那麼不管是「小於」還是「小於等於」條件的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄的主鍵索引中的 next-key 鎖會退化成間隙鎖，其他掃描到的記錄，都是在這些記錄的主鍵索引上加 next-key 鎖。
• 當條件值的記錄「在」表中時：
• 如果是「小於」條件的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄的主鍵索引中的 next-key 鎖會退化成間隙鎖，其他掃描到的記錄，都是在這些記錄的主鍵索引上，加 next-key 鎖。
• 如果是「小於等於」條件的範圍查詢，掃描到終止範圍查詢的記錄時，該記錄的主鍵索引中的 next-key 鎖「不會」退化成間隙鎖，其他掃描到的記錄，都是在這些記錄的主鍵索引上加 next-key 鎖。

非唯一索引等值查詢

當我們用非唯一索引進行等值查詢的時候，因為存在兩個索引，一個是主鍵索引，一個是非唯一索引（二級索引），所以在加鎖時，同時會對這兩個索引都加鎖，但是對主鍵索引加鎖的時候，只有滿足查詢條件的記錄才會對它們的主鍵索引加鎖。

針對非唯一索引等值查詢時，查詢的記錄存不存在，加鎖的規則也會不同：

• 當查詢的記錄「存在」時，由於不是唯一索引，所以肯定存在索引值相同的記錄，於是非唯一索引等值查詢的過程是一個掃描的過程，直到掃描到第一個不符合條件的二級索引記錄就停止掃描，然後在掃描的過程中，對掃描到的二級索引記錄加的是 next-key 鎖，而對於第一個不符合條件的二級索引記錄，該二級索引的  next-key 鎖會退化成間隙鎖。同時，在符合查詢條件的記錄的主鍵索引上加記錄鎖。
• 當查詢的記錄「不存在」時，掃描到第一條不符合條件的二級索引記錄，該二級索引的  next-key 鎖會退化成間隙鎖。因為不存在滿足查詢條件的記錄，所以不會對主鍵索引加鎖。

接下里用兩個實驗來說明。

1、記錄不存在的情況

實驗一：針對非唯一索引等值查詢時，查詢的值不存在的情況。

先來說說非唯一索引等值查詢時，查詢的記錄不存在的情況，因為這個比較簡單。

假設事務 A 對非唯一索引（age）進行了等值查詢，且表中不存在 age = 25 的記錄。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where age = 25 for update;
Empty set (0.00 sec)

事務 A 加鎖變化過程如下：

• 定位到第一條不符合查詢條件的二級索引記錄，即掃描到 age = 39，於是**該二級索引的  next-key 鎖會退化成間隙鎖，範圍是 (22, 39)**。
• 停止查詢

事務 A 在 age = 39 記錄的二級索引上，加了 X 型的間隙鎖，範圍是  (22, 39)。意味著其他事務無法插入 age 值為 23、24、25、26、....、38 這些新記錄。不過對於插入 age = 22 和 age = 39 記錄的語句，在一些情況是可以成功插入的，而一些情況則無法成功插入，具體哪些情況，會在後面說。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

從上圖的分析，可以看到，事務 A 在 age = 39 記錄的二級索引上（INDEX_NAME: index_age  ），加了範圍為 (22, 39) 的 X 型間隙鎖。

此時，如果有其他事務插入了 age 值為 23、24、25、26、....、38 這些新記錄，那麼這些插入語句都會發生阻塞。不過對於插入 age = 39 記錄的語句，在一些情況是可以成功插入的，而一些情況則無法成功插入，具體哪些情況，接下來我們就說！

當有一個事務持有二級索引的間隙鎖 (22, 39) 時，什麼情況下，可以讓其他事務的插入 age = 22 或者 age = 39 記錄的語句成功？又是什麼情況下，插入  age = 22 或者 age = 39 記錄時的語句會被阻塞？

我們先要清楚，什麼情況下插入語句會發生阻塞。

插入語句在插入一條記錄之前，需要先定位到該記錄在 B+樹 的位置，如果插入的位置的下一條記錄的索引上有間隙鎖，才會發生阻塞。

在分析二級索引的間隙鎖是否可以成功插入記錄時，我們要先要知道二級索引樹是如何存放記錄的？

二級索引樹是按照二級索引值（age列）按順序存放的，在相同的二級索引值情況下， 再按主鍵 id 的順序存放。知道了這個前提，我們才能知道執行插入語句的時候，插入的位置的下一條記錄是誰。

基於前面的實驗，事務 A 是在 age = 39 記錄的二級索引上，加了 X 型的間隙鎖，範圍是  (22, 39)。

插入 age = 22 記錄的成功和失敗的情況分別如下：

• 當其他事務插入一條 age = 22，id = 3 的記錄的時候，在二級索引樹上定位到插入的位置，而該位置的下一條是 id = 10、age = 22 的記錄，該記錄的二級索引上沒有間隙鎖，所以這條插入語句可以執行成功。
• 當其他事務插入一條 age = 22，id = 12 的記錄的時候，在二級索引樹上定位到插入的位置，而該位置的下一條是 id = 20、age = 39 的記錄，正好該記錄的二級索引上有間隙鎖，所以這條插入語句會被阻塞，無法插入成功。

插入 age = 39 記錄的成功和失敗的情況分別如下：

• 當其他事務插入一條 age = 39，id = 3 的記錄的時候，在二級索引樹上定位到插入的位置，而該位置的下一條是 id = 20、age = 39 的記錄，正好該記錄的二級索引上有間隙鎖，所以這條插入語句會被阻塞，無法插入成功。

• 當其他事務插入一條 age = 39，id = 21 的記錄的時候，在二級索引樹上定位到插入的位置，而該位置的下一條記錄不存在，也就沒有間隙鎖了，所以這條插入語句可以插入成功。

所以，當有一個事務持有二級索引的間隙鎖 (22, 39) 時，插入 age = 22 或者 age = 39 記錄的語句是否可以執行成功，關鍵還要考慮插入記錄的主鍵值，因為「二級索引值（age列）+主鍵值（id列）」才可以確定插入的位置，確定了插入位置後，就要看插入的位置的下一條記錄是否有間隙鎖，如果有間隙鎖，就會發生阻塞，如果沒有間隙鎖，則可以插入成功。

知道了這個結論之後，我們再回過頭看，非唯一索引等值查詢時，查詢的記錄不存在時，執行select * from performance_schema.data_locks\G; 輸出的結果。

在前面分析輸出結果的時候，我說的結論是：「事務 A 在 age = 39 記錄的二級索引上（INDEX_NAME: index_age  ），加了範圍為 (22, 39) 的 X 型間隙鎖」。這個結論其實還不夠準確，因為只考慮了 LOCK_DATA 第一個數值（39），沒有考慮 LOCK_DATA 第二個數值（20）。

那 LOCK_DATA：39，20 是什麼意思？

• LOCK_DATA 第一個數值，也就是 39， 它代表的是 age 值。從前面我們也知道了，LOCK_DATA 第一個數值是 next-key 鎖和間隙鎖鎖住的範圍的右邊界值。
• LOCK_DATA 第二個數值，也就是 20， 它代表的是 id 值。

之所以 LOCK_DATA 要多顯示一個數值（ID值），是因為針對「當某個事務持有非唯一索引的 (22, 39) 間隙鎖的時候，其他事務是否可以插入 age = 39 新記錄」的問題，還需要考慮插入記錄的 id 值。而 LOCK_DATA 的第二個數值，就是說明在插入 age = 39 新記錄時，哪些範圍的 id 值是不可以插入的。

因此， LOCK_DATA：39，20 + LOCK_MODE : X, GAP 的意思是，事務 A 在 age = 39 記錄的二級索引上（INDEX_NAME: index_age ），加了 age 值範圍為 (22, 39) 的 X 型間隙鎖，**同時針對其他事務插入 age 值為 39 的新記錄時，不允許插入的新記錄的 id 值小於 20 **。如果插入的新記錄的 id 值大於 20，則可以插入成功。

但是我們無法從select * from performance_schema.data_locks\G; 輸出的結果分析出「在插入 age =22 新記錄時，哪些範圍的 id 值是可以插入成功的」，這時候就得自己畫出二級索引的 B+ 樹的結構，然後確定插入位置後，看下該位置的下一條記錄是否存在間隙鎖，如果存在間隙鎖，則無法插入成功，如果不存在間隙鎖，則可以插入成功。

2、記錄存在的情況

實驗二：針對非唯一索引等值查詢時，查詢的值存在的情況。

假設事務 A 對非唯一索引（age）進行了等值查詢，且表中存在 age = 22 的記錄。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where age = 22 for update;
+----+--------+-----+
| id | name   | age |
+----+--------+-----+
| 10 | 山治   |  22 |
+----+--------+-----+
1 row in set (0.00 sec)

事務 A 加鎖變化過程如下：

• 由於不是唯一索引，所以肯定存在值相同的記錄，於是非唯一索引等值查詢的過程是一個掃描的過程，最開始要找的第一行是 age = 22，於是對該二級索引記錄加上範圍為 (21, 22] 的 next-key 鎖。同時，因為 age = 22 符合查詢條件，於是對 age = 22 的記錄的主鍵索引加上記錄鎖，即對 id = 10 這一行加記錄鎖。
• 接著繼續掃描，掃描到的第二行是 age = 39，該記錄是第一個不符合條件的二級索引記錄，所以該二級索引的  next-key 鎖會退化成間隙鎖，範圍是 (22, 39)。
• 停止查詢。

可以看到，事務 A 對主鍵索引和二級索引都加了 X 型的鎖：

• 主鍵索引：
• 在 id = 10 這條記錄的主鍵索引上，加了記錄鎖，意味著其他事務無法更新或者刪除 id = 10 的這一行記錄。
• 二級索引（非唯一索引）：
• 在 age = 22 這條記錄的二級索引上，加了範圍為 (21, 22] 的 next-key 鎖，意味著其他事務無法更新或者刪除 age = 22 的這一些新記錄，不過對於插入 age = 20 和 age = 21 新記錄的語句，在一些情況是可以成功插入的，而一些情況則無法成功插入，具體哪些情況，會在後面說。
• 在 age = 39 這條記錄的二級索引上，加了範圍 (22, 39) 的間隙鎖。意味著其他事務無法插入 age 值為 23、24、..... 、38 的這一些新記錄。不過對於插入 age = 22 和 age = 39 記錄的語句，在一些情況是可以成功插入的，而一些情況則無法成功插入，具體哪些情況，會在後面說。

我們也可以透過 select * from performance_schema.data_locks\G; 這條語句來看看事務 A 加了什麼鎖。

輸出結果如下，我這裡只擷取了行級鎖的內容。

從上圖的分析，可以看到，事務 A 對二級索引（INDEX_NAME: index_age ）加了兩個 X 型鎖，分別是：

• 在 age = 22 這條記錄的二級索引上，加了範圍為 (21, 22] 的 next-key 鎖，意味著其他事務無法更新或者刪除 age = 22 的這一些新記錄，針對是否可以插入 age = 21 和 age = 22 的新記錄，分析如下：
• 是否可以插入 age = 21 的新記錄，還要看插入的新記錄的 id 值，如果插入 age = 21 新記錄的 id 值小於 5，那麼就可以插入成功，因為此時插入的位置的下一條記錄是 id = 5，age = 21 的記錄，該記錄的二級索引上沒有間隙鎖。如果插入 age = 21 新記錄的 id 值大於 5，那麼就無法插入成功，因為此時插入的位置的下一條記錄是 id = 20，age = 39 的記錄，該記錄的二級索引上有間隙鎖。
• 是否可以插入 age = 22 的新記錄，還要看插入的新記錄的 id 值，從 LOCK_DATA : 22, 10 可以得知，其他事務插入 age 值為 22 的新記錄時，如果插入的新記錄的 id 值小於 10，那麼插入語句會發生阻塞；如果插入的新記錄的 id 大於 10，還要看該新記錄插入的位置的下一條記錄是否有間隙鎖，如果沒有間隙鎖則可以插入成功，如果有間隙鎖，則無法插入成功。
• 在 age = 39 這條記錄的二級索引上，加了範圍 (22, 39) 的間隙鎖。意味著其他事務無法插入 age 值為 23、24、..... 、38 的這一些新記錄，針對是否可以插入 age = 22 和 age = 39 的新記錄，分析如下：
• 是否可以插入 age = 22 的新記錄，還要看插入的新記錄的 id 值，如果插入 age = 22 新記錄的 id 值小於 10，那麼插入語句會被阻塞，無法插入，因為此時插入的位置的下一條記錄是 id = 10，age = 22 的記錄，該記錄的二級索引上有間隙鎖（ age = 22 這條記錄的二級索引上有 next-key 鎖）。如果插入 age = 21 新記錄的 id 值大於 10，也無法插入，因為此時插入的位置的下一條記錄是 id = 20，age = 39 的記錄，該記錄的二級索引上有間隙鎖。
• 是否可以插入 age = 39 的新記錄，還要看插入的新記錄的 id 值，從 LOCK_DATA : 39, 20 可以得知，其他事務插入 age 值為 39 的新記錄時，如果插入的新記錄的 id 值小於 20，那麼插入語句會發生阻塞，如果插入的新記錄的 id 大於 20，則可以插入成功。

同時，事務 A  還對主鍵索引（INDEX_NAME: PRIMARY ）加了X 型的記錄鎖：

• 在 id = 10 這條記錄的主鍵索引上，加了記錄鎖，意味著其他事務無法更新或者刪除 id = 10 的這一行記錄。

為什麼這個實驗案例中，需要在二級索引索引上加範圍 (22, 39) 的間隙鎖？

要找到這個問題的答案，我們要明白 MySQL 在可重複讀的隔離級別場景下，為什麼要引入間隙鎖？其實是為了避免幻讀現象的發生。

如果這個實驗案例中：

select * from user where age = 22 for update;

如果事務 A 不在二級索引索引上加範圍 (22, 39) 的間隙鎖，只在二級索引索引上加範圍為 (21, 22] 的 next-key 鎖的話，那麼就會有幻讀的問題。

前面我也說過，在非唯一索引上加了範圍為 (21, 22] 的 next-key 鎖，是無法完全鎖住 age  = 22 新記錄的插入，因為對於是否可以插入 age = 22 的新記錄，還要看插入的新記錄的 id 值，從 LOCK_DATA : 22, 10 可以得知，其他事務插入 age 值為 22 的新記錄時，如果插入的新記錄的 id 值小於 10，那麼插入語句會發生阻塞，如果插入的新記錄的 id 值大於 10，則可以插入成功。

也就是說，只在二級索引索引（非唯一索引）上加範圍為 (21, 22] 的 next-key 鎖，其他事務是有可能插入 age 值為 22 的新記錄的（比如插入一個 age = 22，id = 12 的新記錄），那麼如果事務 A 再一次查詢 age = 22 的記錄的時候，前後兩次查詢 age = 22 的結果集就不一樣了，這時就發生了幻讀的現象。

那麼當在 age = 39 這條記錄的二級索引索引上加了範圍為 (22, 39) 的間隙鎖後，其他事務是無法插入一個 age = 22，id = 12 的新記錄，因為當其他事務插入一條 age = 22，id = 12 的新記錄的時候，在二級索引樹上定位到插入的位置，而該位置的下一條是 id = 20、age = 39 的記錄，正好該記錄的二級索引上有間隙鎖，所以這條插入語句會被阻塞，無法插入成功，這樣就避免幻讀現象的發生。

所以，為了避免幻讀現象的發生，就需要在二級索引索引上加範圍 (22, 39) 的間隙鎖。

非唯一索引範圍查詢

非唯一索引和主鍵索引的範圍查詢的加鎖也有所不同，不同之處在於非唯一索引範圍查詢，索引的 next-key lock 不會有退化為間隙鎖和記錄鎖的情況，也就是非唯一索引進行範圍查詢時，對二級索引記錄加鎖都是加 next-key 鎖。

就帶大家簡單分析一下，事務 A 的這條範圍查詢語句：

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from user where age >= 22  for update;
+----+-----------+-----+
| id | name      | age |
+----+-----------+-----+
| 10 | 山治      |  22 |
| 20 | 香克斯    |  39 |
+----+-----------+-----+
2 rows in set (0.01 sec)

事務 A 的加鎖變化：

• 最開始要找的第一行是 age = 22，雖然範圍查詢語句包含等值查詢，但是這裡不是唯一索引範圍查詢，所以是不會發生退化鎖的現象，因此對該二級索引記錄加 next-key 鎖，範圍是 (21, 22]。同時，對 age = 22 這條記錄的主鍵索引加記錄鎖，即對 id = 10 這一行記錄的主鍵索引加記錄鎖。
• 由於是範圍查詢，接著繼續掃描已經存在的二級索引記錄。掃面的第二行是 age = 39 的二級索引記錄，於是對該二級索引記錄加 next-key 鎖，範圍是 (22, 39]，同時，對 age = 39 這條記錄的主鍵索引加記錄鎖，即對 id = 20 這一行記錄的主鍵索引加記錄鎖。
• 雖然我們看見表中最後一條二級索引記錄是 age = 39 的記錄，但是實際在 Innodb 儲存引擎中，會用一個特殊的記錄來標識最後一條記錄，該特殊的記錄的名字叫 supremum pseudo-record ，所以掃描第二行的時候，也就掃描到了這個特殊記錄的時候，會對該二級索引記錄加的是範圍為  (39, +∞] 的 next-key 鎖。
• 停止查詢

可以看到，事務 A 對主鍵索引和二級索引都加了 X 型的鎖：

• 主鍵索引（id 列）：
• 在 id = 10 這條記錄的主鍵索引上，加了記錄鎖，意味著其他事務無法更新或者刪除 id = 10 的這一行記錄。
• 在 id = 20 這條記錄的主鍵索引上，加了記錄鎖，意味著其他事務無法更新或者刪除 id = 20 的這一行記錄。
• 二級索引（age 列）：
• 在 age = 22 這條記錄的二級索引上，加了範圍為 (21, 22] 的 next-key 鎖，意味著其他事務無法更新或者刪除 age = 22 的這一些新記錄，不過對於是否可以插入 age = 21 和 age = 22 的新記錄，還需要看新記錄的 id 值，有些情況是可以成功插入的，而一些情況則無法插入，具體哪些情況，我們前面也講了。
• 在 age = 39 這條記錄的二級索引上，加了範圍為 (22, 39] 的 next-key 鎖，意味著其他事務無法更新或者刪除 age = 39 的這一些記錄，也無法插入 age 值為 23、24、25、...、38 的這一些新記錄。不過對於是否可以插入 age = 22 和 age = 39 的新記錄，還需要看新記錄的 id 值，有些情況是可以成功插入的，而一些情況則無法插入，具體哪些情況，我們前面也講了。
• 在特殊的記錄（supremum pseudo-record）的二級索引上，加了範圍為 (39, +∞] 的 next-key 鎖，意味著其他事務無法插入 age 值大於 39 的這些新記錄。

在 age >= 22  的範圍查詢中，明明查詢 age = 22 的記錄存在並且屬於等值查詢，為什麼不會像唯一索引那樣，將 age = 22 記錄的二級索引上的 next-key 鎖退化為記錄鎖？

因為 age 欄位是非唯一索引，不具有唯一性，所以如果只加記錄鎖（記錄鎖無法防止插入，只能防止刪除或者修改），就會導致其他事務插入一條 age = 22 的記錄，這樣前後兩次查詢的結果集就不相同了，出現了幻讀現象。

沒有加索引的查詢

前面的案例，我們的查詢語句都有使用索引查詢，也就是查詢記錄的時候，是透過索引掃描的方式查詢的，然後對掃描出來的記錄進行加鎖。

如果鎖定讀查詢語句，沒有使用索引列作為查詢條件，或者查詢語句沒有走索引查詢，導致掃描是全表掃描。那麼，每一條記錄的索引上都會加 next-key 鎖，這樣就相當於鎖住的全表，這時如果其他事務對該表進行增、刪、改操作的時候，都會被阻塞。

不只是鎖定讀查詢語句不加索引才會導致這種情況，update 和 delete 語句如果查詢條件不加索引，那麼由於掃描的方式是全表掃描，於是就會對每一條記錄的索引上都會加 next-key 鎖，這樣就相當於鎖住的全表。

因此，線上上在執行 update、delete、select ... for update 等具有加鎖性質的語句，一定要檢查語句是否走了索引，如果是全表掃描的話，會對每一個索引加 next-key 鎖，相當於把整個表鎖住了，這是挺嚴重的問題。

總結

這次我以 MySQL 8.0.26 版本，在可重複讀隔離級別之下，做了幾個實驗，讓大家瞭解了唯一索引和非唯一索引的行級鎖的加鎖規則。

我這裡總結下，  MySQL 行級鎖的加鎖規則。

唯一索引等值查詢：

• 當查詢的記錄是「存在」的，在索引樹上定位到這一條記錄後，將該記錄的索引中的 next-key lock 會退化成「記錄鎖」。
• 當查詢的記錄是「不存在」的，在索引樹找到第一條大於該查詢記錄的記錄後，將該記錄的索引中的 next-key lock 會退化成「間隙鎖」。

非唯一索引等值查詢：

• 當查詢的記錄「存在」時，由於不是唯一索引，所以肯定存在索引值相同的記錄，於是非唯一索引等值查詢的過程是一個掃描的過程，直到掃描到第一個不符合條件的二級索引記錄就停止掃描，然後在掃描的過程中，對掃描到的二級索引記錄加的是 next-key 鎖，而對於第一個不符合條件的二級索引記錄，該二級索引的 next-key 鎖會退化成間隙鎖。同時，在符合查詢條件的記錄的主鍵索引上加記錄鎖。
• 當查詢的記錄「不存在」時，掃描到第一條不符合條件的二級索引記錄，該二級索引的  next-key 鎖會退化成間隙鎖。因為不存在滿足查詢條件的記錄，所以不會對主鍵索引加鎖。

非唯一索引和主鍵索引的範圍查詢的加鎖規則不同之處在於：

• 唯一索引在滿足一些條件的時候，索引的 next-key lock 退化為間隙鎖或者記錄鎖。
• 非唯一索引範圍查詢，索引的 next-key lock 不會退化為間隙鎖和記錄鎖。

其實理解 MySQL 為什麼要這樣加鎖，主要要以避免幻讀角度去分析，這樣就很容易理解這些加鎖的規則了。

還有一件很重要的事情，線上上在執行 update、delete、select ... for update 等具有加鎖性質的語句，一定要檢查語句是否走了索引，如果是全表掃描的話，會對每一個索引加 next-key 鎖，相當於把整個表鎖住了，這是挺嚴重的問題。

就說到這啦， 我們下次見啦！