首先眾所周知帖旨，InnoDB 三種行鎖：
Record Lock（記錄鎖）：鎖住某一行記錄
Gap Lock（間隙鎖）：鎖住一段左開右開的區(qū)間
Next-key Lock（臨鍵鎖）：鎖住一段左開右閉的區(qū)間
哪些語句上面會加行鎖芳室？
1）對于常見的 DML 語句（如 UPDATE、DELETE 和 INSERT ）窒盐，InnoDB 會自動給相應(yīng)的記錄行加寫鎖
2）默認(rèn)情況下對于普通 SELECT 語句，InnoDB 不會加任何鎖淆衷，但是在 Serializable 隔離級別下會加行級讀鎖
上面兩種是隱式鎖定捂贿，InnoDB 也支持通過特定的語句進(jìn)行顯式鎖定：
3）SELECT * FROM table_name WHERE ... FOR UPDATE，加行級寫鎖
4）SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE巾乳，加行級讀鎖
前置知識就不過多介紹了胚膊，在學(xué)習(xí)具體行鎖加鎖規(guī)則之前故俐，小伙伴們需要記住加鎖規(guī)則的兩條核心：
1）查找過程中訪問到的對象才會加鎖
這句話該怎么理解？比如有主鍵 id 為 1 2 3 4 5 ... 10 的10 條記錄紊婉，我們要找到 id = 7 的記錄。注意辑舷，查找并不是從第一行開始一行一行地進(jìn)行遍歷喻犁，而是根據(jù) B+ 樹的特性進(jìn)行二分查找，所以一般存儲引擎只會訪問到要找的記錄行（id = 7）的相鄰區(qū)間
2）加鎖的基本單位是 Next-key Lock
下面結(jié)合實例幫助大伙分析一條 SQL 語句上面究竟被 InnoDB 自動加上了多少個鎖
假設(shè)有這么一張 user 表何缓，id 為主鍵（唯一索引）肢础，a 是普通索引（非唯一索引），b 都是普通的列碌廓，其上沒有任何索引：
id (唯一索引) a (非唯一索引) b
10 4 Alice
15 8 Bob
20 16 Cilly
25 32 Druid
30 64 Erik
案例 1：唯一索引等值查詢
當(dāng)我們用唯一索引進(jìn)行等值查詢的時候传轰，根據(jù)查詢的記錄是否存在，加鎖的規(guī)則會有所不同：
當(dāng)查詢的記錄是存在的谷婆，Next-key Lock 會退化成記錄鎖
當(dāng)查詢的記錄是不存在的，Next-key Lock 會退化成間隙鎖
查詢的記錄存在
先來看個查詢的記錄存在的案例：
select * from user
where id = 25
for update;
結(jié)合加鎖的兩條核心：查找過程中訪問到的對象才會加鎖 + 加鎖的基本單位是 Next-key Lock（左開右閉），我們可以分析出纱控，這條語句的加鎖范圍是 (20, 25]
不過梳星，由于這個唯一索引等值查詢的記錄 id = 25 是存在的，因此异袄，Next-key Lock 會退化成記錄鎖通砍，因此最終的加鎖范圍是 id = 25 這一行
查詢的記錄不存在
再來看查詢的記錄不存在的案例：
select * from user
where id = 22
for update;
結(jié)合加鎖的兩條核心：查找過程中訪問到的對象才會加鎖 + 加鎖的基本單位是 Next-key Lock（左開右閉），我們可以分析出烤蜕，這條語句的加鎖范圍是 (20, 25]
這里為什么是 (20封孙，25] 而不是 (20, 22]，因為 id = 22 的記錄不存在呀讽营，InnoDB 先找到 id = 20 的記錄虎忌，發(fā)現(xiàn)不匹配，于是繼續(xù)往下找斑匪，發(fā)現(xiàn) id = 25呐籽，因此，id = 25 的這一行被掃描到了蚀瘸，所以整體的加鎖范圍是 (20, 25]
由于這個唯一索引等值查詢的記錄 id = 22 是不存在的狡蝶，因此，Next-key Lock 會退化成間隙鎖贮勃，因此最終在主鍵 id 上的加鎖范圍是 Gap Lock (20, 25)
案例 2：唯一索引范圍查詢
唯一索引范圍查詢的規(guī)則和等值查詢的規(guī)則一樣贪惹，只有一個區(qū)別，就是唯一索引的范圍查詢需要一直向右遍歷到第一個不滿足條件的記錄寂嘉，下面結(jié)合案例來分析：
select * from user
where id >= 20 and id < 22
for update;
先來看語句查詢條件的前半部分 id >= 20奏瞬，因此枫绅，這條語句最開始要找的第一行是 id = 20，結(jié)合加鎖的兩個核心硼端，需要加上 Next-key Lock (15,20]并淋。又由于 id 是唯一索引，且 id = 20 的這行記錄是存在的珍昨，因此會退化成記錄鎖县耽，也就是只會對 id = 20 這一行加鎖。
再來看語句查詢條件的后半部分 id < 22镣典，由于是范圍查找兔毙，就會繼續(xù)往后找第一個不滿足條件的記錄，也就是會找到 id = 25 這一行停下來兄春，然后加 Next-key Lock (20, 25]澎剥，重點(diǎn)來了，但由于 id = 25 不滿足 id < 22赶舆，因此會退化成間隙鎖哑姚，加鎖范圍變?yōu)?(20, 25)。
所以涌乳，上述語句在主鍵 id 上的最終的加鎖范圍是 Record Lock id = 20 以及 Gap Lock (20, 25)
案例 3：非唯一索引等值查詢
當(dāng)我們用非唯一索引進(jìn)行等值查詢的時候蜻懦，根據(jù)查詢的記錄是否存在，加鎖的規(guī)則會有所不同：
當(dāng)查詢的記錄是存在的夕晓，除了會加 Next-key Lock 外宛乃，還會額外加間隙鎖（規(guī)則是向下遍歷到第一個不符合條件的值才能停止），也就是會加兩把鎖
很好記憶蒸辆，就是要查找記錄的左區(qū)間加 Next-key Lock征炼，右區(qū)間加 Gap lock
當(dāng)查詢的記錄是不存在的，Next-key Lock 會退化成間隙鎖（這個規(guī)則和唯一索引的等值查詢是一樣的）
查詢的記錄存在
先來看個查詢的記錄存在的案例：
select * from user
where a = 16
for update;
結(jié)合加鎖的兩條核心躬贡，這條語句首先會對普通索引 a 加上 Next-key Lock谆奥，范圍是 (8,16]
又因為是非唯一索引等值查詢，且查詢的記錄 a= 16 是存在的拂玻，所以還會加上間隙鎖酸些，規(guī)則是向下遍歷到第一個不符合條件的值才能停止，因此間隙鎖的范圍是 (16,32)
所以檐蚜，上述語句在普通索引 a 上的最終加鎖范圍是 Next-key Lock (8,16] 以及 Gap Lock (16,32)
查詢的記錄不存在
再來看查詢的記錄不存在的案例：
select * from user
where a = 18
for update;
結(jié)合加鎖的兩條核心魄懂，這條語句首先會對普通索引 a 加上 Next-key Lock，范圍是 (16,32]
但是由于查詢的記錄 a = 18 是不存在的闯第，因此 Next-key Lock 會退化為間隙鎖市栗，即最終在普通索引 a 上的加鎖范圍是 (16,32)。
案例 4：非唯一索引范圍查詢
范圍查詢和等值查詢的區(qū)別在上面唯一索引章節(jié)已經(jīng)介紹過了，就是范圍查詢需要一直向右遍歷到第一個不滿足條件的記錄填帽，和唯一索引范圍查詢不同的是蛛淋，非唯一索引的范圍查詢并不會退化成 Record Lock 或者 Gap Lock。
select * from user
where a >= 16 and a < 18
for update;
先來看語句查詢條件的前半部分 a >= 16篡腌，因此褐荷，這條語句最開始要找的第一行是 a = 16，結(jié)合加鎖的兩個核心哀蘑，需要加上 Next-key Lock (8,16]诚卸。雖然非唯一索引 a = 16 的這行記錄是存在的，但此時并不會像唯一索引那樣退化成記錄鎖绘迁。
再來看語句查詢條件的后半部分 a < 18，由于是范圍查找卒密，就會繼續(xù)往后找第一個不滿足條件的記錄缀台，也就是會找到 id = 32 這一行停下來，然后加 Next-key Lock (16, 32]哮奇。雖然 id = 32 不滿足 id < 18膛腐，但此時并不會向唯一索引那樣退化成間隙鎖。
所以鼎俘，上述語句在普通索引 a 上的最終的加鎖范圍是 Next-key Lock (8, 16] 和 (16, 32]哲身，也就是 (8, 32]。
