首先眾所周知，InnoDB 三種行鎖：

Record Lock（記錄鎖） ：鎖住某一行記錄

Gap Lock（間隙鎖） ：鎖住一段左開右開的區(qū)間

Next-key Lock（臨鍵鎖） ：鎖住一段左開右閉的區(qū)間

哪些語(yǔ)句上面會(huì)加行鎖？

1）對(duì)于常見的 DML 語(yǔ)句（如 UPDATE、DELETE 和 INSERT ），InnoDB 會(huì)自動(dòng)給相應(yīng)的記錄行加寫鎖

2）默認(rèn)情況下對(duì)于普通 SELECT 語(yǔ)句，InnoDB 不會(huì)加任何鎖，但是在 Serializable 隔離級(jí)別下會(huì)加行級(jí)讀鎖

上面兩種是隱式鎖定，InnoDB 也支持通過特定的語(yǔ)句進(jìn)行顯式鎖定：

3）SELECT * FROM table_name WHERE ... FOR UPDATE，加行級(jí)寫鎖

4）SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE，加行級(jí)讀鎖

前置知識(shí)就不過多介紹了，在學(xué)習(xí)具體行鎖加鎖規(guī)則之前，小伙伴們需要記住加鎖規(guī)則的兩條核心：

1）查找過程中訪問到的對(duì)象才會(huì)加鎖

這句話該怎么理解？比如有主鍵 id 為 1 2 3 4 5 ... 10 的 10 條記錄，我們要找到 id = 7 的記錄。注意，查找并不是從第一行開始一行一行地進(jìn)行遍歷，而是根據(jù) B+ 樹的特性進(jìn)行二分查找，所以一般存儲(chǔ)引擎只會(huì)訪問到要找的記錄行（id = 7）的相鄰區(qū)間

2）加鎖的基本單位是 Next-key Lock

下面結(jié)合實(shí)例幫助大伙分析一條 SQL 語(yǔ)句上面究竟被 InnoDB 自動(dòng)加上了多少個(gè)鎖

假設(shè)有這么一張 user 表，id 為主鍵（唯一索引），a 是普通索引（非唯一索引），b都是普通的列，其上沒有任何索引：

案例 1：唯一索引等值查詢

當(dāng)我們用唯一索引進(jìn)行等值查詢的時(shí)候，根據(jù)查詢的記錄是否存在，加鎖的規(guī)則會(huì)有所不同：

當(dāng)查詢的記錄是存在的，Next-key Lock 會(huì)退化成記錄鎖

當(dāng)查詢的記錄是不存在的，Next-key Lock 會(huì)退化成間隙鎖

查詢的記錄存在

先來(lái)看個(gè)查詢的記錄存在的案例：

select*fromuser
whereid=25
forupdate;

結(jié)合加鎖的兩條核心：查找過程中訪問到的對(duì)象才會(huì)加鎖 + 加鎖的基本單位是 Next-key Lock（左開右閉），我們可以分析出，這條語(yǔ)句的加鎖范圍是 (20, 25]

不過，由于這個(gè)唯一索引等值查詢的記錄 id = 25 是存在的，因此，Next-key Lock 會(huì)退化成記錄鎖，因此最終的加鎖范圍是 id = 25 這一行

查詢的記錄不存在

再來(lái)看查詢的記錄不存在的案例：

select*fromuser
whereid=22
forupdate;

結(jié)合加鎖的兩條核心：查找過程中訪問到的對(duì)象才會(huì)加鎖 + 加鎖的基本單位是 Next-key Lock（左開右閉），我們可以分析出，這條語(yǔ)句的加鎖范圍是 (20, 25]

這里為什么是 (20，25] 而不是 (20, 22]，因?yàn)?id = 22 的記錄不存在呀，InnoDB 先找到 id = 20 的記錄，發(fā)現(xiàn)不匹配，于是繼續(xù)往下找，發(fā)現(xiàn) id = 25，因此，id = 25 的這一行被掃描到了，所以整體的加鎖范圍是 (20, 25]

由于這個(gè)唯一索引等值查詢的記錄 id = 22 是不存在的，因此，Next-key Lock 會(huì)退化成間隙鎖，因此最終在主鍵 id 上的加鎖范圍是 Gap Lock (20, 25)

案例 2：唯一索引范圍查詢

唯一索引范圍查詢的規(guī)則和等值查詢的規(guī)則一樣，只有一個(gè)區(qū)別，就是唯一索引的范圍查詢需要一直向右遍歷到第一個(gè)不滿足條件的記錄，下面結(jié)合案例來(lái)分析：

select*fromuser
whereid>=20andid

	

	先來(lái)看語(yǔ)句查詢條件的前半部分 id >= 20，因此，這條語(yǔ)句最開始要找的第一行是 id = 20，結(jié)合加鎖的兩個(gè)核心，需要加上 Next-key Lock (15,20]。又由于 id 是唯一索引，且 id = 20 的這行記錄是存在的，因此會(huì)退化成記錄鎖，也就是只會(huì)對(duì) id = 20 這一行加鎖。

	再來(lái)看語(yǔ)句查詢條件的后半部分 id < 22，由于是范圍查找，就會(huì)繼續(xù)往后找第一個(gè)不滿足條件的記錄，也就是會(huì)找到 id = 25 這一行停下來(lái)，然后加 Next-key Lock (20, 25]，重點(diǎn)來(lái)了，但由于 id = 25 不滿足 id < 22，因此會(huì)退化成間隙鎖，加鎖范圍變?yōu)?(20, 25)。

	所以，上述語(yǔ)句在主鍵 id 上的最終的加鎖范圍是 Record Lock id = 20 以及 Gap Lock (20, 25)

	案例 3：非唯一索引等值查詢

	當(dāng)我們用非唯一索引進(jìn)行等值查詢的時(shí)候，根據(jù)查詢的記錄是否存在，加鎖的規(guī)則會(huì)有所不同：

	1、當(dāng)查詢的記錄是存在的，除了會(huì)加 Next-key Lock 外，還會(huì)額外加間隙鎖（規(guī)則是向下遍歷到第一個(gè)不符合條件的值才能停止），也就是會(huì)加兩把鎖

	很好記憶，就是要查找記錄的左區(qū)間加 Next-key Lock，右區(qū)間加 Gap lock

	2、當(dāng)查詢的記錄是不存在的，Next-key Lock 會(huì)退化成間隙鎖（這個(gè)規(guī)則和唯一索引的等值查詢是一樣的）

	查詢的記錄存在

	先來(lái)看個(gè)查詢的記錄存在的案例：

	
select*fromuser
wherea=16
forupdate;


	

	結(jié)合加鎖的兩條核心，這條語(yǔ)句首先會(huì)對(duì)普通索引 a 加上 Next-key Lock，范圍是 (8,16]

	又因?yàn)槭欠俏ㄒ凰饕戎挡樵?，且查詢的記?a= 16 是存在的，所以還會(huì)加上間隙鎖，規(guī)則是向下遍歷到第一個(gè)不符合條件的值才能停止，因此間隙鎖的范圍是 (16,32)

	所以，上述語(yǔ)句在普通索引 a 上的最終加鎖范圍是 Next-key Lock (8,16] 以及 Gap Lock (16,32)

	查詢的記錄不存在

	再來(lái)看查詢的記錄不存在的案例：

	
select*fromuser
wherea=18
forupdate;


	

	結(jié)合加鎖的兩條核心，這條語(yǔ)句首先會(huì)對(duì)普通索引 a 加上 Next-key Lock，范圍是 (16,32]

	但是由于查詢的記錄 a = 18 是不存在的，因此 Next-key Lock 會(huì)退化為間隙鎖，即最終在普通索引 a 上的加鎖范圍是 (16,32)。

	案例 4：非唯一索引范圍查詢

	范圍查詢和等值查詢的區(qū)別在上面唯一索引章節(jié)已經(jīng)介紹過了，就是范圍查詢需要一直向右遍歷到第一個(gè)不滿足條件的記錄，和唯一索引范圍查詢不同的是，非唯一索引的范圍查詢并不會(huì)退化成 Record Lock 或者 Gap Lock。

	
select*fromuser
wherea>=16anda

	

	先來(lái)看語(yǔ)句查詢條件的前半部分 a >= 16，因此，這條語(yǔ)句最開始要找的第一行是 a = 16，結(jié)合加鎖的兩個(gè)核心，需要加上 Next-key Lock (8,16]。雖然非唯一索引 a = 16的這行記錄是存在的，但此時(shí)并不會(huì)像唯一索引那樣退化成記錄鎖。

	再來(lái)看語(yǔ)句查詢條件的后半部分 a < 18，由于是范圍查找，就會(huì)繼續(xù)往后找第一個(gè)不滿足條件的記錄，也就是會(huì)找到 id = 32 這一行停下來(lái)，然后加 Next-key Lock (16, 32]。雖然 id = 32 不滿足 id < 18，但此時(shí)并不會(huì)向唯一索引那樣退化成間隙鎖。

	所以，上述語(yǔ)句在普通索引 a 上的最終的加鎖范圍是 Next-key Lock (8, 16] 和 (16, 32]，也就是 (8, 32]。

	





	審核編輯：劉清