十個人有九個答錯，另外一個只對一半：數據庫的鎖，到底鎖的是什么？
在MySQL數據庫中，為了解決并發問題，引入了很多的鎖機制，很多時候，數據庫的鎖是在有數據庫操作的過程中自動添加的。
所以，這就導致很多程序員經常會忽略數據庫的鎖機制的真正的原理。比如，我經常在面試中會問候選人，你知道MySQL Innodb的鎖，到底鎖的是什么嗎?
關于這個問題的回答，我聽到過很多種，但是很少有人可以把他回答的很完美。因為想要回答好這個問題，需要對數據庫的隔離級別、索引等都有一定的了解才行。
MySQL Innodb的鎖的相關介紹，在MySQL的官方文檔(https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-insert-intention-locks )中有一定的介紹，本文的介紹也是基于這篇官方文檔的。
Record Lock
Record Lock，翻譯成記錄鎖，是加在索引記錄上的鎖。例如，SELECT c1 FROM t WHERE c1 = 10 For UPDATE;會對c1=10這條記錄加鎖，為了防止任何其他事務插入、更新或刪除c1值為10的行。
需要特別注意的是，記錄鎖鎖定的是索引記錄。即使表沒有定義索引，InnoDB也會創建一個隱藏的聚集索引，并使用這個索引來鎖定記錄。
Gap Lock
Gap Lock，翻譯成間隙鎖，他指的是在索引記錄之間的間隙上的鎖，或者在第一個索引記錄之前或最后一個索引記錄之后的間隙上的鎖。
那么，這里所謂的Gap(間隙)又怎么理解呢?
Gap指的是InnoDB的索引數據結構中可以插入新值的位置。
當你用語句SELECT…FOR UPDATE鎖定一組行時。InnoDB可以創建鎖，應用于索引中的實際值以及他們之間的間隙。例如，如果選擇所有大于10的值進行更新，間隙鎖將阻止另一個事務插入大于10的新值。
既然是鎖，那么就可能會影響到數據庫的并發性，所以，間隙鎖只有在Repeatable Reads這種隔離級別中才會起作用。
在Repeatable Reads這種隔離下，對于鎖定的讀操作(select … for update 、 lock in share mode)、update操作、delete操作時，會進行如下的加鎖：
- 對于具有唯一搜索條件的唯一索引，InnoDB只鎖定找到的索引記錄，而不會鎖定間隙。
- 對于其他搜索條件，InnoDB鎖定掃描的索引范圍，使用gap lock或next-key lock來阻塞其他事務插入范圍覆蓋的間隙。
也就是說，對于SELECT FOR UPDATE、LOCK IN SHARE MODE、UPDATE和DELETE等語句處理時，除了對唯一索引的唯一搜索外都會獲取gap鎖或next-key鎖，即鎖住其掃描的范圍。
Next-Key Lock
Next-Key鎖是索引記錄上的記錄鎖和索引記錄之前間隙上的間隙鎖的組合。
假設一個索引包含值10、11、13和20。此索引可能的next-key鎖包括以下區間:
- (-∞, 10]
- (10, 11]
- (11, 13]
- (13, 20]
- (20, ∞ ]
對于最后一個間隙，∞不是一個真正的索引記錄，因此，實際上，這個next-key鎖只鎖定最大索引值之后的間隙。
所以，Next-Key 的鎖的范圍都是左開右閉的。
Next-Key Lock和Gap Lock一樣，只有在InnoDB的RR隔離級別中才會生效。
Repeatable Reads能解決幻讀
很多人看過網上的關于數據庫事務級別的介紹，會認為MySQL中Repeatable Reads能解決不可重復讀的問題，但是不能解決幻讀，只有Serializable才能解決。但其實，這種想法是不對的。
因為MySQL跟標準RR不一樣，標準的Repeatable Reads確實存在幻讀問題，但InnoDB中的Repeatable Reads是通過next-key lock解決了RR的幻讀問題的。
因為我們知道，因為有了next-key lock，所以在需要加行鎖的時候，會同時在索引的間隙中加鎖，這就使得其他事務無法在這些間隙中插入記錄，這就解決了幻讀的問題。
關于這個問題，引起過廣泛的討論，可以參考：https://github.com/Yhzhtk/note/issues/42 ，這里有很多大神發表過自己的看法。
MySQL的加鎖原則
前面介紹過了Record Lock、Gap Lock和Next-Key Lock，但是并沒有說明加鎖規則。關于加鎖規則，我是看了丁奇大佬的《MySQL實戰45講》中的文章之后理解的，他總結的加鎖規則里面，包含了兩個“原則”、兩個“優化”和一個“bug”：
原則 1：加鎖的基本單位是 next-key lock。是一個前開后閉區間。原則 2：查找過程中訪問到的對象才會加鎖。優化 1：索引上的等值查詢，給唯一索引加鎖的時候，next-key lock 退化為行鎖。優化 2：索引上的等值查詢，向右遍歷時且最后一個值不滿足等值條件的時候，next-key lock 退化為間隙鎖。一個 bug：唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。
假如，數據庫表中當前有以下記錄：
當我們執行update t set d=d+1 where id = 7的時候，由于表 t 中沒有 id=7 的記錄，所以：
- 根據原則 1，加鎖單位是 next-key lock，session A 加鎖范圍就是 (5,10];
- 根據優化 2，這是一個等值查詢 (id=7)，而 id=10 不滿足查詢條件，next-key lock 退化成間隙鎖，因此最終加鎖的范圍是 (5,10)。
當我們執行select * from t where id>=10 and id<11 for update的時候：
- 根據原則 1，加鎖單位是 next-key lock，會給 (5,10]加上 next-key lock，范圍查找就往后繼續找，找到 id=15 這一行停下來
- 根據優化 1，主鍵 id 上的等值條件，退化成行鎖，只加了 id=10 這一行的行鎖。
- 根據原則 2，訪問到的都要加鎖，因此需要加 next-key lock(10,15]。因此最終加的是行鎖 id=10 和 next-key lock(10,15]。
當我們執行select * from t where id>10 and id<=15 for update的時候：* 根據原則 1，加鎖單位是 next-key lock，會給 (10,15]加上 next-key lock，并且因為 id 是唯一鍵，所以循環判斷到 id=15 這一行就應該停止了。* 但是，InnoDB 會往前掃描到第一個不滿足條件的行為止，也就是 id=20。而且由于這是個范圍掃描，因此索引 id 上的 (15,20]這個 next-key lock 也會被鎖上。
假如，數據庫表中當前有以下記錄：
當我們執行select id from t where c=5 lock in share mode的時候：
- 根據原則 1，加鎖單位是 next-key lock，因此會給 (0,5]加上 next-key lock。要注意 c 是普通索引，因此僅訪問 c=5 這一條記錄是不能馬上停下來的，需要向右遍歷，查到 c=10 才放棄。
- 根據原則 2，訪問到的都要加鎖，因此要給 (5,10]加 next-key lock。
- 根據優化 2：等值判斷，向右遍歷，最后一個值不滿足 c=5 這個等值條件，因此退化成間隙鎖 (5,10)。
- 根據原則 2 ，只有訪問到的對象才會加鎖，這個查詢使用覆蓋索引，并不需要訪問主鍵索引，所以主鍵索引上沒有加任何鎖。
當我們執行select * from t where c>=10 and c<11 for update的時候：
- 根據原則 1，加鎖單位是 next-key lock，會給 (5,10]加上 next-key lock，范圍查找就往后繼續找，找到 id=15 這一行停下來
- 根據原則 2，訪問到的都要加鎖，因此需要加 next-key lock(10,15]。
- 由于索引 c 是非唯一索引，沒有優化規則，也就是說不會蛻變為行鎖，因此最終 sesion A 加的鎖是，索引 c 上的 (5,10] 和 (10,15] 這兩個 next-key lock。
總結
以上，我們介紹了InnoDB中的鎖機制，一共有三種鎖，分別是Record Lock、Gap Lock和Next-Key Lock。
Record Lock表示記錄鎖，鎖的是索引記錄。Gap Lock是間隙鎖，說的是索引記錄之間的間隙。Next-Key Lock是Record Lock和Gap Lock的組合，同時鎖索引記錄和間隙。他的范圍是左開右閉的。
InnoDB的RR級別中，加鎖的基本單位是 next-key lock，只要掃描到的數據都會加鎖。唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。
同時，為了提升性能和并發度，也有兩個優化點：
- 索引上的等值查詢，給唯一索引加鎖的時候，next-key lock 退化為行鎖。
- 索引上的等值查詢，向右遍歷時且最后一個值不滿足等值條件的時候，next-key lock 退化為間隙鎖。
關于鎖的介紹，就是這么多了，但是其實，RR的隔離級別引入的這些鎖，雖然一定程度上可解決很多如幻讀這樣的問題，但是也會帶來一些副作用，比如并發度降低、容易導致死鎖等。
后面我們再來單獨介紹一下為什么RR作為InnoDB的默認級別，卻"不受待見"，很多大廠都會把數據庫默認級別修改為RC。
