?大家好，我是樹哥。

在之前的文章里，我們討論了關(guān)于 MySQL 的許多問題，包括：

1. MySQL 啥時候用表鎖，啥時候用行鎖？
2. MySQL 不同隔離級別，都使用了什么鎖？
3. MySQL 啥時候用記錄鎖，啥時候用間隙鎖？

在這些文章中，我們大致了解了一些加鎖的情況。但實際上 MySQL 的加鎖規(guī)則是怎樣的，我還不是特別清楚。所以今天我們就來深入了解下 MySQL 的加鎖規(guī)則。

MySQL 的加鎖規(guī)則到底是怎樣的？

迷霧找真相

為了弄清楚這些加鎖規(guī)則，我查閱了許多資料。但在這些資料中，我覺得比較有質(zhì)量的只有兩個：一個是極客時間《MySQL 45 講》第 20/21 節(jié)講得內(nèi)容，另一個是一篇從源碼角度解析加鎖規(guī)則的文章。

《MySQL 45 講》是丁奇老師出的一個專欄，現(xiàn)在是騰訊云數(shù)據(jù)庫負(fù)責(zé)人。在該專欄的第 21、22 節(jié)中講到了具體的加鎖規(guī)則，并且也舉了非常多的例子。本文也將摘取其中一些內(nèi)容，來跟大家討論學(xué)習(xí)。

另一篇從源碼角度講加鎖規(guī)則的，是網(wǎng)名為「小孩子」的網(wǎng)友寫得一篇文章，其后續(xù)出了一本書叫《從根上了解 MySQL》，內(nèi)容非常多并且很詳細。這篇文章從源碼角度從頭到尾分析了整個加鎖規(guī)則，講得還是比較詳細。

在看著兩份資料之前，我總是嘗試去找到一個簡單好記的加鎖規(guī)律，但看完之后覺得：這或許不太可能。丁奇大神在其專欄也提到他是怎么去分析加鎖規(guī)則的。

首先說明一下，這些加鎖規(guī)則我沒在別的地方看到過有類似的總結(jié)，以前我自己判斷的時候都是想著代碼里面的實現(xiàn)來腦補的。這次為了總結(jié)成不看代碼的同學(xué)也能理解的規(guī)則，是我又重新刷了代碼臨時總結(jié)出來的。

可以看到，就連大神也是想著代碼腦補加鎖規(guī)律的。再結(jié)合「小孩子」從源碼角度去分析加鎖規(guī)則，我一下子就覺得：或許還是該深入到源碼角度，才能一窺真相。

即使后面丁奇老師為了方便我們理解，也總結(jié)出了一些加鎖（如下圖所示）。但實際上這些加鎖規(guī)則也沒啥規(guī)律，只能是記著就好。此外，他也提出：我們需要用動態(tài)的眼光去看加鎖。言外之意就是，這些規(guī)則可能都是變化的，也不一定是完全正確的。

圖片來自極客時間專欄

看到這里，我會想：那我們應(yīng)該怎么學(xué)習(xí) MySQL 的加鎖規(guī)則呢？

我思考了片刻，給出的答案是：我們可以按照丁奇老師總結(jié)出的加鎖規(guī)則先行學(xué)習(xí)，后續(xù)再深入源碼層面不斷地補足一些細節(jié)。

MySQL 加鎖全局視角

在講一些具體加鎖規(guī)則之前，我覺得有必要先給大家一個 MySQL 加鎖的全局視角。這個是丁奇老師在文章中沒講到的，但我覺得如果不知道全局視角，那么會影響到對一些規(guī)則的理解。

我們知道 MySQL 分成了 Server 層和存儲引擎兩部分，每當(dāng)執(zhí)行一個查詢時，Server 層負(fù)責(zé)生成執(zhí)行計劃，然后交給存儲引擎去執(zhí)行。其整個過程可以這樣描述：

1. Server 層向 Innodb 獲取到掃描區(qū)間的第 1 條記錄。
2. Innodb 通過 B+ 樹定位到掃描區(qū)間的第 1 條記錄，然后返回給 Server 層。
3. Server 層判斷是否符合搜索條件，如果符合則發(fā)送給客戶端，不負(fù)責(zé)則跳過。接著繼續(xù)向 Innodb 要下一條記錄。
4. Innodb 繼續(xù)根據(jù) B+ 樹的雙休鏈表找到下一條記錄，會執(zhí)行具體的 row_search_mvcc 函數(shù)做加鎖等操作，返回給 Server 層。
5. Server 層繼續(xù)處理該條記錄，并向 Innodb 要下一條記錄。
6. 繼續(xù)不停執(zhí)行上述過程，直到 Innodb 讀到一條不符合邊界條件的記錄為止。

通過上面這個過程，我想讓大家明白兩個重要的認(rèn)識：

1. Innodb 并不是一次性把所有數(shù)據(jù)找到，然后返回給 Server 層的，而是會循環(huán)很多次。
2. row_search_mvcc 這個函數(shù)是做具體的加鎖、加什么鎖的重要邏輯，并且由于 Server 層與 Innodb 會循環(huán)多次，因此該函數(shù)也是會執(zhí)行多次的。

弄懂了上面兩個認(rèn)識，會對后續(xù)大家理解有很大幫助。例如：對于 select * from user where id >= 5 進行分析的時候，為什么會出現(xiàn)說第一次加鎖是精確查詢？它明明是范圍查詢呀！這是因為第一次是要尋找到 id = 5 的記錄，對于 Innodb 來說，它就是精確查找，不是范圍查找。隨后找到 id = 5 的記錄之后，就要找 id > 5 的記錄了，此時就變成了范圍查找了。

MySQL 加鎖規(guī)則

這里的加鎖規(guī)則，我直接引用丁奇老師的總結(jié)：兩個原則、兩個優(yōu)化、一個 bug。

• 原則 1：加鎖的基本單位是 next-key lock。其中 next-key lock 是前開后閉區(qū)間，例如：(2, 5]。
• 原則 2：查找過程中訪問到的對象才會加鎖。
• 優(yōu)化 1：索引上的等值查詢，給唯一索引加鎖的時候，next-key lock 退化為行鎖。
• 優(yōu)化 2：索引上的等值查詢，向右遍歷時且最后一個值不滿足等值條件的時候，next-key lock 退化為間隙鎖。
• 一個 bug：唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。

對于原則 1 說的：加鎖的基本單位是 Next-Key 鎖，意思是默認(rèn)都是先加上 Next-Key，之后根據(jù) 2 個優(yōu)化點選擇性退化為行鎖或間隙鎖。

對于原則 2 說的：訪問到的對象才會加鎖，意思是如果直接索引覆蓋到了，不需要回表，那么就不會對聚簇索引加鎖。這樣的話，其他事務(wù)就可以對聚簇索引進行操作，而不會阻塞。

為了解釋這些規(guī)則，建立表 t 并插入一些數(shù)據(jù)。

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

等值查詢間隙鎖

如下圖所示的例子，是一個等值條件加間隙鎖的例子。

圖片來自極客時間專欄

在事務(wù) A 中，要查找 id = 7 的記錄，其查找過程為：從左到右查找 id 聚簇索引，依次對比 0、5 兩個索引，發(fā)現(xiàn)不對。接著，對比 10 這個索引，發(fā)現(xiàn) 7 <10，于是停止搜索。根據(jù)原則 1 默認(rèn)給其加上一個 Next-Key 鎖，即 (5, 10]。根據(jù)優(yōu)化 2 退化為間隙鎖，即 (5,10)。

所以，session B 要插入 id=8 的記錄會被鎖住，而 session 修改 id=10 這行是可以的。

非唯一索引等值鎖

圖片來自極客時間專欄

在事務(wù) A 中，要查找 c=5 的記錄，其中 c 是非唯一索引。其查找過程為：從左到右查找 c 索引，找到了 c=5 的索引，根據(jù)原則 1 對其加 Next-Key 鎖，即 (0,5]。

由于普通索引可能重復(fù)，因此其還會繼續(xù)往后搜索，接著搜索到 10，根據(jù)原則 2，訪問到的都要加鎖，因此再給其加 Next-Key 鎖，即 (5,10]。由于這個還負(fù)責(zé)優(yōu)化 2：等值判斷，向右遍歷，最后一個不滿足等值條件，因此退化為間隙鎖 (5,10)。

此外，根據(jù)原則 2，只有訪問到的對象才會加鎖。這個查詢使用查詢覆蓋索引，并不需要訪問主鍵索引，所以主鍵索引上沒有加任何鎖。也就是說 (0,5] 和 (5,10) 這兩個鎖，只在索引 c 上加鎖，并不在主鍵索引上加鎖，因此 session B 可以執(zhí)行。

session C 中插入一個 c 為 7 的值，c 為 7 的值在 (5,10) 之間，因此會被鎖住。

主鍵索引范圍鎖

對于我們這個表 t，下面這兩條查詢語句，加鎖范圍相同嗎？

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

在邏輯上，這兩條查語句肯定是等價的，但是它們的加鎖規(guī)則不太一樣?，F(xiàn)在，我們就讓 session A 執(zhí)行第二個查詢語句，來看看加鎖效果。

圖片來自極客時間專欄

我們來分析一下整體的加鎖規(guī)則吧。

事務(wù) A 開始執(zhí)行的時候，要找到 id 為 10 的記錄，于是從左到右找到了 id 為 10 的索引。根據(jù)原則 1 會給其加 Next-Key 鎖，即 (5,10]。根據(jù)優(yōu)化 1，id = 10 是等值查詢，因此其退化為行鎖，即只對 id = 10 這行加了行鎖。

接著繼續(xù)進行范圍查找，找到 id=15 這一行，繼續(xù)加 Next-Key 鎖 (10,15]。這時候 id=15 大于 11，因此其不再查找。TODO

非唯一索引范圍鎖

下面的 c 字段是非唯一普通索引，使用了范圍查詢。

圖片來自極客時間專欄

事務(wù) A 開始執(zhí)行的時候，要找到 id 為 10 的記錄，于是根據(jù)原則 1 加了 Next-Key 鎖，即 (5,10]。由于索引 C 是非唯一索引，沒有優(yōu)化規(guī)則，因此不會退化為行鎖。因此對于事務(wù) A 來說，索引 C 上加的是 (5,10] 和 (10,15] 兩個 Next-Key 鎖。

所以當(dāng) session B 和 session C 要操作 c 值為 8 和 15 的數(shù)據(jù)時會被阻塞。

總結(jié)

最后我們總結(jié)一下 MySQL 的加鎖規(guī)則：

• 首先，明白 server 層與存儲引擎層是多次數(shù)據(jù)交互的，并不是存儲引擎層一次性查找完數(shù)據(jù)。
• 其次，根據(jù)兩個原則去分析加鎖的范圍，核心是加鎖單位是 Next-Key 鎖。
• 最后，根據(jù)兩個優(yōu)化去進行鎖退化，核心因素是唯一索引及等值查詢。

其中「兩個原則、兩個優(yōu)化」是：

• 原則 1：加鎖的基本單位是 next-key lock。其中 next-key lock 是前開后閉區(qū)間，例如：(2, 5]。
• 原則 2：查找過程中訪問到的對象才會加鎖。
• 優(yōu)化 1：索引上的等值查詢，給唯一索引加鎖的時候，next-key lock 退化為行鎖。
• 優(yōu)化 2：索引上的等值查詢，向右遍歷時且最后一個值不滿足等值條件的時候，next-key lock 退化為間隙鎖。

通過上面這樣的加鎖規(guī)則，我們就可以有一個大致的分析思路，至少能開始分析加鎖規(guī)律了。

但要注意的是，實際上的情況非常復(fù)雜，例如 limit 參數(shù)也會影響加鎖的范圍，非唯一索引多個值夜會影響鎖范圍。簡單地說，就是有很多特例的情況，我們還需要繼續(xù)去積累。

參考資料

• 20 | 幻讀是什么，幻讀有什么問題？
• 21 | 為什么我只改一行的語句，鎖這么多？
• 完整版：Innodb 到底是怎么加鎖的