求你了,別再說資料庫鎖的只是索引了!!!

MC811-MM118發表於2021-12-13

GitHub 21.3k Star 的Java工程師成神之路,不來了解一下嗎!

GitHub 21.3k Star 的Java工程師成神之路,真的不來了解一下嗎!

在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。

相關文章