GitHub 21.3k Star 的Java工程師成神之路，不來(lái)了解一下嗎！

GitHub 21.3k Star 的Java工程師成神之路，真的不來(lái)了解一下嗎！

在MySQL數(shù)據(jù)庫(kù)中，為了解決并發(fā)問(wèn)題，引入了很多的鎖機(jī)制，很多時(shí)候，數(shù)據(jù)庫(kù)的鎖是在有數(shù)據(jù)庫(kù)操作的過(guò)程中自動(dòng)添加的。

所以，這就導(dǎo)致很多程序員經(jīng)常會(huì)忽略數(shù)據(jù)庫(kù)的鎖機(jī)制的真正的原理。比如，我經(jīng)常在面試中會(huì)問(wèn)候選人，你知道MySQL Innodb的鎖，到底鎖的是什么嗎？

關(guān)于這個(gè)問(wèn)題的回答，我聽到過(guò)很多種，但是很少有人可以把他回答的很完美。因?yàn)橄胍卮鸷眠@個(gè)問(wèn)題，需要對(duì)數(shù)據(jù)庫(kù)的隔離級(jí)別、索引等都有一定的了解才行。

MySQL Innodb的鎖的相關(guān)介紹，在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;會(huì)對(duì)c1=10這條記錄加鎖，為了防止任何其他事務(wù)插入、更新或刪除c1值為10的行。

需要特別注意的是，記錄鎖鎖定的是索引記錄。即使表沒(méi)有定義索引，InnoDB也會(huì)創(chuàng)建一個(gè)隱藏的聚集索引，并使用這個(gè)索引來(lái)鎖定記錄。

Gap Lock

Gap Lock，翻譯成間隙鎖，他指的是在索引記錄之間的間隙上的鎖，或者在第一個(gè)索引記錄之前或最后一個(gè)索引記錄之后的間隙上的鎖。

那么，這里所謂的Gap（間隙）又怎么理解呢？

Gap指的是InnoDB的索引數(shù)據(jù)結(jié)構(gòu)中可以插入新值的位置。

當(dāng)你用語(yǔ)句SELECT…FOR UPDATE鎖定一組行時(shí)。InnoDB可以創(chuàng)建鎖，應(yīng)用于索引中的實(shí)際值以及他們之間的間隙。例如，如果選擇所有大于10的值進(jìn)行更新，間隙鎖將阻止另一個(gè)事務(wù)插入大于10的新值。

既然是鎖，那么就可能會(huì)影響到數(shù)據(jù)庫(kù)的并發(fā)性，所以，間隙鎖只有在Repeatable Reads這種隔離級(jí)別中才會(huì)起作用。

在Repeatable Reads這種隔離下，對(duì)于鎖定的讀操作（select … for update 、 lock in share mode)、update操作、delete操作時(shí)，會(huì)進(jìn)行如下的加鎖：

• 對(duì)于具有唯一搜索條件的唯一索引，InnoDB只鎖定找到的索引記錄，而不會(huì)鎖定間隙。

• 對(duì)于其他搜索條件，InnoDB鎖定掃描的索引范圍，使用gap lock或next-key lock來(lái)阻塞其他事務(wù)插入范圍覆蓋的間隙。

也就是說(shuō)，對(duì)于SELECT FOR UPDATE、LOCK IN SHARE MODE、UPDATE和DELETE等語(yǔ)句處理時(shí)，除了對(duì)唯一索引的唯一搜索外都會(huì)獲取gap鎖或next-key鎖，即鎖住其掃描的范圍。

Next-Key Lock

Next-Key鎖是索引記錄上的記錄鎖和索引記錄之前間隙上的間隙鎖的組合。

假設(shè)一個(gè)索引包含值10、11、13和20。此索引可能的next-key鎖包括以下區(qū)間:

(-∞, 10] (10, 11] (11, 13] (13, 20] (20, ∞ ]

對(duì)于最后一個(gè)間隙，∞不是一個(gè)真正的索引記錄，因此，實(shí)際上，這個(gè)next-key鎖只鎖定最大索引值之后的間隙。

所以，Next-Key 的鎖的范圍都是左開右閉的。

Next-Key Lock和Gap Lock一樣，只有在InnoDB的RR隔離級(jí)別中才會(huì)生效。

Repeatable Reads能解決幻讀

很多人看過(guò)網(wǎng)上的關(guān)于數(shù)據(jù)庫(kù)事務(wù)級(jí)別的介紹，會(huì)認(rèn)為MySQL中Repeatable Reads能解決不可重復(fù)讀的問(wèn)題，但是不能解決幻讀，只有Serializable才能解決。但其實(shí)，這種想法是不對(duì)的。

因?yàn)镸ySQL跟標(biāo)準(zhǔn)RR不一樣，標(biāo)準(zhǔn)的Repeatable Reads確實(shí)存在幻讀問(wèn)題，但I(xiàn)nnoDB中的Repeatable Reads是通過(guò)next-key lock解決了RR的幻讀問(wèn)題的。

因?yàn)槲覀冎?#xff0c;因?yàn)橛辛薾ext-key lock，所以在需要加行鎖的時(shí)候，會(huì)同時(shí)在索引的間隙中加鎖，這就使得其他事務(wù)無(wú)法在這些間隙中插入記錄，這就解決了幻讀的問(wèn)題。

關(guān)于這個(gè)問(wèn)題，引起過(guò)廣泛的討論，可以參考：https://github.com/Yhzhtk/note/issues/42 ，這里有很多大神發(fā)表過(guò)自己的看法。

MySQL的加鎖原則

前面介紹過(guò)了Record Lock、Gap Lock和Next-Key Lock，但是并沒(méi)有說(shuō)明加鎖規(guī)則。關(guān)于加鎖規(guī)則，我是看了丁奇大佬的《MySQL實(shí)戰(zhàn)45講》中的文章之后理解的，他總結(jié)的加鎖規(guī)則里面，包含了兩個(gè)“原則”、兩個(gè)“優(yōu)化”和一個(gè)“bug”：

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

假如，數(shù)據(jù)庫(kù)表中當(dāng)前有以下記錄：

當(dāng)我們執(zhí)行update t set d=d+1 where id = 7的時(shí)候，由于表 t 中沒(méi)有 id=7 的記錄，所以：

• 根據(jù)原則 1，加鎖單位是 next-key lock，session A 加鎖范圍就是 (5,10]；
• 根據(jù)優(yōu)化 2，這是一個(gè)等值查詢 (id=7)，而 id=10 不滿足查詢條件，next-key lock 退化成間隙鎖，因此最終加鎖的范圍是 (5,10)。

當(dāng)我們執(zhí)行select * from t where id>=10 and id<11 for update的時(shí)候：

• 根據(jù)原則 1，加鎖單位是 next-key lock，會(huì)給 (5,10]加上 next-key lock，范圍查找就往后繼續(xù)找，找到 id=15 這一行停下來(lái)
• 根據(jù)優(yōu)化 1，主鍵 id 上的等值條件，退化成行鎖，只加了 id=10 這一行的行鎖。
• 根據(jù)原則 2，訪問(wèn)到的都要加鎖，因此需要加 next-key lock(10,15]。因此最終加的是行鎖 id=10 和 next-key lock(10,15]。

當(dāng)我們執(zhí)行select * from t where id>10 and id<=15 for update的時(shí)候： * 根據(jù)原則 1，加鎖單位是 next-key lock，會(huì)給 (10,15]加上 next-key lock，并且因?yàn)?id 是唯一鍵，所以循環(huán)判斷到 id=15 這一行就應(yīng)該停止了。 * 但是，InnoDB 會(huì)往前掃描到第一個(gè)不滿足條件的行為止，也就是 id=20。而且由于這是個(gè)范圍掃描，因此索引 id 上的 (15,20]這個(gè) next-key lock 也會(huì)被鎖上。

假如，數(shù)據(jù)庫(kù)表中當(dāng)前有以下記錄：

當(dāng)我們執(zhí)行select id from t where c=5 lock in share mode的時(shí)候：

• 根據(jù)原則 1，加鎖單位是 next-key lock，因此會(huì)給 (0,5]加上 next-key lock。要注意 c 是普通索引，因此僅訪問(wèn) c=5 這一條記錄是不能馬上停下來(lái)的，需要向右遍歷，查到 c=10 才放棄。
• 根據(jù)原則 2，訪問(wèn)到的都要加鎖，因此要給 (5,10]加 next-key lock。
• 根據(jù)優(yōu)化 2：等值判斷，向右遍歷，最后一個(gè)值不滿足 c=5 這個(gè)等值條件，因此退化成間隙鎖 (5,10)。
• 根據(jù)原則 2 ，只有訪問(wèn)到的對(duì)象才會(huì)加鎖，這個(gè)查詢使用覆蓋索引，并不需要訪問(wèn)主鍵索引，所以主鍵索引上沒(méi)有加任何鎖。

當(dāng)我們執(zhí)行select * from t where c>=10 and c<11 for update的時(shí)候：

• 根據(jù)原則 1，加鎖單位是 next-key lock，會(huì)給 (5,10]加上 next-key lock，范圍查找就往后繼續(xù)找，找到 id=15 這一行停下來(lái)
• 根據(jù)原則 2，訪問(wèn)到的都要加鎖，因此需要加 next-key lock(10,15]。
• 由于索引 c 是非唯一索引，沒(méi)有優(yōu)化規(guī)則，也就是說(shuō)不會(huì)蛻變?yōu)樾墟i，因此最終 sesion A 加的鎖是，索引 c 上的 (5,10] 和 (10,15] 這兩個(gè) next-key lock。

總結(jié)

以上，我們介紹了InnoDB中的鎖機(jī)制，一共有三種鎖，分別是Record Lock、Gap Lock和Next-Key Lock。

Record Lock表示記錄鎖，鎖的是索引記錄。 Gap Lock是間隙鎖，說(shuō)的是索引記錄之間的間隙。 Next-Key Lock是Record Lock和Gap Lock的組合，同時(shí)鎖索引記錄和間隙。他的范圍是左開右閉的。

InnoDB的RR級(jí)別中，加鎖的基本單位是 next-key lock，只要掃描到的數(shù)據(jù)都會(huì)加鎖。唯一索引上的范圍查詢會(huì)訪問(wèn)到不滿足條件的第一個(gè)值為止。

同時(shí)，為了提升性能和并發(fā)度，也有兩個(gè)優(yōu)化點(diǎn)：

• 索引上的等值查詢，給唯一索引加鎖的時(shí)候，next-key lock 退化為行鎖。
• 索引上的等值查詢，向右遍歷時(shí)且最后一個(gè)值不滿足等值條件的時(shí)候，next-key lock 退化為間隙鎖。

關(guān)于鎖的介紹，就是這么多了，但是其實(shí)，RR的隔離級(jí)別引入的這些鎖，雖然一定程度上可解決很多如幻讀這樣的問(wèn)題，但是也會(huì)帶來(lái)一些副作用，比如并發(fā)度降低、容易導(dǎo)致死鎖等。

后面我們?cè)賮?lái)單獨(dú)介紹一下為什么RR作為InnoDB的默認(rèn)級(jí)別，卻"不受待見"，很多大廠都會(huì)把數(shù)據(jù)庫(kù)默認(rèn)級(jí)別修改為RC。

總結(jié)

以上是生活随笔為你收集整理的求你了，别再说数据库锁的只是索引了！！！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。