本文主要是帶大家快速了解 InnoDB 中鎖相關(guān)的知識(shí)

基礎(chǔ)概念解析和RocketMQ詳細(xì)的源碼解析

http://xiazai.jb51.net/202105/yuanma/RocketMQ_jb51.rar

為什么需要加鎖

首先，為什么要加鎖？我想我不用多說了，想象接下來的場(chǎng)景你就能 GET 了。

你在商場(chǎng)的衛(wèi)生間上廁所，此時(shí)你一定會(huì)做的操作是啥？鎖門。如果不鎖門，上廁所上著上著，啪一下門就被打開了，可能大概也許似乎貌似有那么一丁點(diǎn)的不太合適。

數(shù)據(jù)也是一樣，在并發(fā)的場(chǎng)景下，如果不對(duì)數(shù)據(jù)加鎖，會(huì)直接破壞數(shù)據(jù)的一致性，并且如果你的業(yè)務(wù)涉及到錢，那后果就更嚴(yán)重了。

鎖門表情包

鎖的分類

在 InnoDB 中，都有哪些鎖？其實(shí)你應(yīng)該已經(jīng)知道了很多了，例如面試中會(huì)問你存儲(chǔ)引擎 MyISAM 和 InnoDB 的區(qū)別，你會(huì)說 MyIASM 只有表鎖，但是 InnoDB 同時(shí)支持行鎖和表鎖。你可能還會(huì)被問到樂觀鎖和悲觀鎖的區(qū)別是啥。

鎖的概念、名詞很多，如果你沒有對(duì)鎖構(gòu)建出一個(gè)完整的世界觀，那么你理解起來就會(huì)比較有阻礙，接下來我們把這些鎖給分一下類。

按照鎖的粒度

按照鎖的粒度進(jìn)行劃分可以分為：

• 表鎖
• 行鎖

這里就不討論頁鎖了，頁鎖是 BDB（BerkeleyDB） 存儲(chǔ)引擎中才有的概念，我們這里主要討論 InnoDB 存儲(chǔ)引擎。

按照鎖的思想

按照加鎖的思想可以分為：

• 悲觀鎖
• 樂觀鎖

這里的悲觀、樂觀和你平時(shí)理解的名詞是同一個(gè)意思。樂觀鎖認(rèn)為大概率不會(huì)發(fā)生沖突，只在必要的時(shí)候加鎖。而悲觀鎖認(rèn)為大概率會(huì)沖突，所以無論是否必要加鎖都會(huì)執(zhí)行加鎖操作。

按照兼容性

按照兼容性可以把鎖劃分為：

• 共享鎖
• 排他鎖

被加上共享鎖的資源，能夠和其他人進(jìn)行共享，而如果被加上了排他鎖，其他人在拿不到這把鎖的情況下是無法進(jìn)行任何操作的。

按照鎖的實(shí)現(xiàn)

這里的實(shí)現(xiàn)就是 InnoDB 中具體的鎖的種類了，分別有：

• 意向鎖（Intention Locks）
• 記錄鎖（Record Locks）
• 間隙鎖（Gap Locks）
• 臨鍵鎖（Next-Key Locks）
• 插入意向鎖（Insert Intention Locks）
• 自增鎖（AUTO-INC Locks）

即使按照這種分類來對(duì)鎖進(jìn)行了劃分，看到了這么多的鎖的名詞可能仍然會(huì)有點(diǎn)懵。比如我SELECT ... FOR UPDATE 的時(shí)候到底加的是什么鎖？

我們應(yīng)該透過現(xiàn)象看本質(zhì)，本質(zhì)是什么？本質(zhì)是鎖到底加在了什么對(duì)象上，而這個(gè)很好回答：

• 加在了表上
• 加在了行上

而對(duì)于加在行上的鎖，其本質(zhì)又是什么？本質(zhì)是將鎖加在了索引上。

意向鎖

在 InnoDB 中支持了不同粒度的鎖，行鎖和表鎖。例如lock tables命令就會(huì)持有對(duì)應(yīng)表的排他鎖。為了使多種不同粒度的鎖更實(shí)用，InnoDB 設(shè)計(jì)了意向鎖。

意向鎖是一種表級(jí)鎖，它表明了接下來的事務(wù)中，會(huì)使用哪種類型的鎖，它有以下兩種類型：

• 共享意向鎖（IS） 表明該事務(wù)會(huì)打算對(duì)表中的記錄加共享鎖
• 獨(dú)占意向鎖（IX） 則是加排他鎖

例如，select ... for share就是加的共享意向鎖，而SELECT .. FOR UPDATE則是加的獨(dú)占意向鎖。其規(guī)則如下：

• 一個(gè)事務(wù)如果想要獲取某張表中某行的共享鎖，它必須先獲取該表的共享意向鎖，或者獨(dú)占意向鎖。
• 同理，如果想獲取排他鎖，它必須先獲取獨(dú)占意向鎖

下圖是這幾種鎖的組合下相互互斥、兼容的情況

對(duì)照上面的表，在相互兼容的情況下，對(duì)應(yīng)的事務(wù)就能獲取鎖，但是如果不兼容則無法獲取鎖，直到不兼容的鎖釋放之后才能獲取。

看到這里你可能就會(huì)有問題了，那既然意向鎖除了 LOCK TBALES 之外什么都不阻塞。那我要它何用？

還是通過例子，假設(shè)事務(wù) A 獲取了 student 表中 id = 100 這行的共享鎖，之后事務(wù) B 需要申請(qǐng) student 表的排他鎖。而這兩把鎖明顯是沖突的，而且還是對(duì)于同一行。

那 InnoDB 需要如何感知 A 獲取了這把鎖？遍歷整個(gè) B+ 樹嗎？不，答案就是意向鎖。事務(wù) B 申請(qǐng)寫表的排他鎖時(shí)，InnoDB 會(huì)發(fā)現(xiàn)事務(wù) A 已經(jīng)獲取了該表的意向共享鎖，說明 student 表中已經(jīng)有記錄被共享鎖鎖住了。此時(shí)就會(huì)阻塞住。

并且，意向鎖除了像LOCK TABLES這種操作之外，不會(huì)阻塞其他任何操作。換句話說，意向鎖只會(huì)和表級(jí)別的鎖之間發(fā)生沖突，而不會(huì)和行級(jí)鎖發(fā)生沖突。因?yàn)橐庀蜴i的主要目的是為了表明有人即將、或者正在鎖定某一行。

就像你去圖書館找書，你并不需要每個(gè)書架挨著挨著找，直接去服務(wù)臺(tái)用電腦一搜，就知道圖書館有沒有這本書。

記錄鎖

這就是記錄鎖，是行鎖的一種。記錄鎖的鎖定對(duì)象是對(duì)應(yīng)那行數(shù)據(jù)所對(duì)應(yīng)的索引。對(duì)索引不太清楚的可以看看這篇文章。

當(dāng)我們執(zhí)行SELECT * FROM student WHERE id = 1 FOR UPDATE語句時(shí)，就會(huì)對(duì)值為1的索引加上記錄鎖。至于要是一張表里沒有索引該怎么辦？這個(gè)問題在上面提到的文章中也解釋過了，當(dāng)一張表沒有定義主鍵時(shí)，InnoDB 會(huì)創(chuàng)建一個(gè)隱藏的RowID，并以此 RowID 來創(chuàng)建聚簇索引。后續(xù)的記錄鎖也會(huì)加到這個(gè)隱藏的聚簇索引上。

當(dāng)我們開啟一個(gè)事務(wù)去更新 id = 1 這行數(shù)據(jù)時(shí)，如果我們不馬上提交事務(wù)，然后再啟一個(gè)事務(wù)去更新 id = 1 的行，此時(shí)使用 show engine innodb status查看，我們可以看到lock_mode X locks rec but not gap waiting的字樣。

X是排他鎖的意思，從這可以看出來，記錄鎖其實(shí)也可以分為共享鎖、排他鎖模式。當(dāng)我們使用FOR UPDATE是排他，而使用LOCK IN SHARE MODE 則是共享。

而在上面字樣中出現(xiàn)的 gap 就是另一種行鎖的實(shí)現(xiàn)間隙鎖。

間隙鎖

對(duì)于間隙鎖（Gap Locks）而言，其鎖定的對(duì)象也是索引。為了更好的了解間隙鎖，我們舉個(gè)例子。

SELECT name FROM student WHERE age BETWEEN 18 AND 25 FOR UPDATE

假設(shè)我們?yōu)?age 建立了非聚簇索引，運(yùn)行該語句會(huì)阻止其他事務(wù)向 student 表中新增 18-25 的數(shù)據(jù)，無論表中是否真的有 age 為 18-25 的數(shù)據(jù)。因?yàn)殚g隙鎖的本質(zhì)是鎖住了索引上的一個(gè)范圍，而 InnoDB 中索引在底層的B+樹上的存儲(chǔ)是有序的。

再舉個(gè)例子:

SELECT * FROM student WHERE age = 10 FOR UPDATE;

值得注意的是，這里的 age 不是唯一索引，就是一個(gè)簡單的非聚簇索引。此時(shí)會(huì)給 age = 10 的數(shù)據(jù)加上記錄鎖，并且鎖定 age < 10 的 Gap。如果當(dāng)前這個(gè)事務(wù)不提交，其他事務(wù)如果要插入一條 age < 10 的數(shù)據(jù)時(shí)，會(huì)被阻塞住。

間隙鎖是 MySQL 在對(duì)性能、并發(fā)綜合考慮之下的一種折中的解決方案，并且只在**可重復(fù)讀（RR）下可用，如果當(dāng)前事務(wù)的隔離級(jí)別為讀已提交（RC）**時(shí)，MySQL會(huì)將間隙鎖禁用。

剛剛說了，記錄鎖分為共享、排他，間隙鎖其實(shí)也一樣。但是不同于記錄鎖的一點(diǎn)，共享間隙鎖、排他間隙鎖相互不互斥，這是怎么回事？

我們還是需要透過現(xiàn)象看到本質(zhì)，間隙鎖的目的是什么？

為了防止其他事務(wù)在 Gap 中插入數(shù)據(jù)

那共享、排他間隙鎖在這個(gè)目標(biāo)上是一致的，所以是可以同時(shí)存在的。

臨鍵鎖

臨鍵鎖（Next-Key Locks）是 InnoDB 最后一種行鎖的實(shí)現(xiàn)，臨鍵鎖實(shí)際上是記錄鎖和間隙鎖的組合。換句話說，臨鍵鎖會(huì)給對(duì)應(yīng)的索引加上記錄鎖，并且外加鎖定一個(gè)區(qū)間。

但是并不是所有臨鍵鎖都是這么玩的，對(duì)于下面的SQL:

SELECT * FROM student WHERE id = 23;

在這種情況下，id是主鍵，唯一索引，無論其他事務(wù)插入了多少數(shù)據(jù)，id = 23這條數(shù)據(jù)永遠(yuǎn)也只有一條。此時(shí)再加一個(gè)間隙鎖就完全沒有必要了，反而會(huì)降低并發(fā)。所以，在使用的索引是唯一索引的時(shí)候，臨鍵鎖會(huì)降級(jí)為記錄鎖。

假設(shè)我們有10，20，30總共3條索引數(shù)據(jù)。那么對(duì)應(yīng)臨鍵鎖來說，可能鎖定的區(qū)間就會(huì)如下：

• (∞, 10]
• (10, 20]
• (20, 30]
• (30, ∞)

InnoDB 的默認(rèn)事務(wù)隔離級(jí)別為可重復(fù)讀（RR），在這個(gè)情況下，InnoDB 就會(huì)使用臨鍵鎖，以防止幻讀的出現(xiàn)。

簡單解釋一下幻讀，就是在事務(wù)內(nèi)，你執(zhí)行了兩次查詢，第一次查詢出來 5 條數(shù)據(jù)，但是第二次再查，居然查出了 7 條數(shù)據(jù)，這就是幻讀。

可能你在之前的很多博客，或者面試八股文上，了解到過 InnoDB 的RR事務(wù)隔離級(jí)別可以防止幻讀，RR防止幻讀的關(guān)鍵就是臨鍵鎖。

舉個(gè)例子，假設(shè) student 表中就兩行數(shù)據(jù)，id分別為90和110.

SELECT * FROM student WHERE id > 100 FOR UPDATE;

當(dāng)執(zhí)行該 SQL 語句之后，InnoDB就會(huì)給區(qū)間 (90, 110] 和（110,∞) 加上間隙鎖，同時(shí)給 id=110 的索引加上記錄鎖。這樣以來，其他事務(wù)就無法向這個(gè)區(qū)間內(nèi)新增數(shù)據(jù)，即使 100 根本不存在。

插入意向鎖

接下來是插入意向鎖（Insert Intention Locks），當(dāng)我們執(zhí)行 INSERT 語句之前會(huì)加的鎖。本質(zhì)上是間隙鎖的一種。

還是舉個(gè)例子，假設(shè)我們現(xiàn)在有索引記錄10、20，事務(wù)A、B分別插入索引值為14、16的數(shù)據(jù)，此時(shí)事務(wù)A和B都會(huì)用插入意向鎖鎖住 10-20 之間的 Gap，獲取了插入意向鎖之后就會(huì)獲取14、16的排他鎖。

此時(shí)事務(wù)A和B是不會(huì)相互阻塞的，因?yàn)樗麄儾迦氲氖遣煌男小?/p>

自增鎖

最后是自增鎖（AUTO-INC Locks），自增鎖的本質(zhì)是表鎖，較為特殊。當(dāng)事務(wù) A 向包含了 AUTO_INCREMENT 列的表中新增數(shù)據(jù)時(shí)，就會(huì)持有自增鎖。而此時(shí)其他的事務(wù) B 則必須要等待，以保證事務(wù) A 取得連續(xù)的自增值，中間不會(huì)有斷層。

好了，通過下面鏈接獲取MQ學(xué)習(xí)資料，包含基礎(chǔ)概念解析和RocketMQ詳細(xì)的源碼解析，持續(xù)更新中，大家一定不要錯(cuò)過這份學(xué)習(xí)資料哦。

http://xiazai.jb51.net/202105/yuanma/RocketMQ_jb51.rar (必收藏)

以上就是簡單了解 MySQL 中相關(guān)的鎖的詳細(xì)內(nèi)容，更多關(guān)于MySQL鎖相關(guān)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！