本系列包含：

• 【數(shù)據(jù)庫】MySQL 的存儲(chǔ)引擎
• 【數(shù)據(jù)庫】B 樹、B+ 樹、索引
• 【數(shù)據(jù)庫】從事務(wù)到鎖機(jī)制
• 【數(shù)據(jù)庫】MySQL 中的鎖機(jī)制

數(shù)據(jù)庫鎖定機(jī)制簡(jiǎn)單來說，就是數(shù)據(jù)庫為了保證數(shù)據(jù)的一致性，而使各種共享資源在被并發(fā)訪問變得有序所設(shè)計(jì)的一種規(guī)則。

MySQL 數(shù)據(jù)庫由于其自身架構(gòu)的特點(diǎn)，存在多種數(shù)據(jù)存儲(chǔ)引擎，每種存儲(chǔ)引擎的鎖定機(jī)制都是為各自所面對(duì)的特定場(chǎng)景而優(yōu)化設(shè)計(jì)，所以各存儲(chǔ)引擎的鎖定機(jī)制也有較大區(qū)別。

一、表級(jí)鎖、行級(jí)鎖、頁級(jí)鎖

MySQL各存儲(chǔ)引擎使用了三種類型（級(jí)別）的鎖定機(jī)制：表級(jí)鎖定，行級(jí)鎖定、頁級(jí)鎖定。

1.1 表級(jí)鎖

表級(jí)別的鎖定是 MySQL 各存儲(chǔ)引擎中最大顆粒度的鎖定機(jī)制。該鎖定機(jī)制最大的特點(diǎn)是實(shí)現(xiàn)邏輯非常簡(jiǎn)單，帶來的系統(tǒng)負(fù)面影響最小。所以獲取鎖和釋放鎖的速度很快。

當(dāng)然，鎖定顆粒度大所帶來最大的負(fù)面影響就是出現(xiàn)鎖定資源爭(zhēng)用的概率也會(huì)最高，致使并發(fā)度大打折扣。

使用表級(jí)鎖定的主要是 MyISAM，MEMORY，CSV 等一些非事務(wù)性存儲(chǔ)引擎。

1.2 行級(jí)鎖

行級(jí)鎖定最大的特點(diǎn)就是鎖定對(duì)象的顆粒度很小，由于鎖定顆粒度很小，所以發(fā)生鎖定資源爭(zhēng)用的概率也最小，能夠給予應(yīng)用程序盡可能大的并發(fā)處理能力而提高一些需要高并發(fā)應(yīng)用系統(tǒng)的整體性能。

雖然能夠在并發(fā)處理能力上面有較大的優(yōu)勢(shì)，但是行級(jí)鎖定也因此帶來了不少弊端。

由于鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖需要做的事情也更多，帶來的消耗自然也就更大了。此外，行級(jí)鎖定也最容易發(fā)生死鎖。

使用行級(jí)鎖定的主要是 InnoDB 存儲(chǔ)引擎。

1.3 頁級(jí)鎖

頁級(jí)鎖定是 MySQL 中比較獨(dú)特的一種鎖定級(jí)別。頁級(jí)鎖定的特點(diǎn)是鎖定顆粒度介于行級(jí)鎖定與表級(jí)鎖之間，所以獲取鎖定所需要的資源開銷，以及所能提供的并發(fā)處理能力也同樣是介于上面二者之間。

使用頁級(jí)鎖定的主要是 BerkeleyDB 存儲(chǔ)引擎。

1.4 總結(jié)

總的來說，MySQL 這 3 種鎖的特性可大致歸納如下：

• 表級(jí)鎖：開銷小，加鎖快；不會(huì)出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低；
• 行級(jí)鎖：開銷大，加鎖慢；會(huì)出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高；
• 頁面鎖：開銷和加鎖時(shí)間界于表鎖和行鎖之間；會(huì)出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般。

二、共享鎖、排它鎖

InnoDB 實(shí)現(xiàn)了標(biāo)準(zhǔn)的行級(jí)鎖，包括兩種：共享鎖（簡(jiǎn)稱 s 鎖）、排它鎖（簡(jiǎn)稱 x 鎖）。

對(duì)于共享鎖而言，對(duì)當(dāng)前行加共享鎖，不會(huì)阻塞其他事務(wù)對(duì)同一行的讀請(qǐng)求，但會(huì)阻塞對(duì)同一行的寫請(qǐng)求。只有當(dāng)讀鎖釋放后，才會(huì)執(zhí)行其它事物的寫操作。

對(duì)于排它鎖而言，會(huì)阻塞其他事務(wù)對(duì)同一行的讀和寫操作，只有當(dāng)寫鎖釋放后，才會(huì)執(zhí)行其它事務(wù)的讀寫操作。

簡(jiǎn)而言之，就是：讀鎖會(huì)阻塞寫 (X)，但是不會(huì)堵塞讀 (S)。而寫鎖則會(huì)把讀 (S) 和寫 (X) 都堵塞。

對(duì)于InnoDB 在 RR（MySQL默認(rèn)隔離級(jí)別）而言，對(duì)于 update、delete 和 insert 語句， 會(huì)自動(dòng)給涉及數(shù)據(jù)集加排它鎖（X）；

對(duì)于普通 select 語句，innodb 不會(huì)加任何鎖。如果想在 select 操作的時(shí)候加上 S 鎖 或者 X 鎖，需要我們手動(dòng)加鎖。

-- 加共享鎖（S）
select * from table_name where ... lock in share mode

-- 加排它鎖（X)
select * from table_name where ... for update

用 select … in share mode 獲得共享鎖，主要用在需要數(shù)據(jù)依存關(guān)系時(shí)來確認(rèn)某行記錄是否存在，并確保沒有人對(duì)這個(gè)記錄進(jìn)行 update 或者 delete 操作。

但是如果當(dāng)前事務(wù)也需要對(duì)該記錄進(jìn)行更新操作,則有可能造成死鎖，對(duì)于鎖定行記錄后需要進(jìn)行更新操作的應(yīng)用，應(yīng)該使用 select … for update 方式獲得排他鎖。

三、加鎖模式

3.1 記錄鎖（Record Locks）

記錄鎖其實(shí)很好理解，對(duì)表中的記錄加鎖，叫做記錄鎖，簡(jiǎn)稱行鎖。比如

SELECT * FROM `test` WHERE `id`=1 FOR UPDATE;

它會(huì)在 id=1 的記錄上加上記錄鎖，以阻止其他事務(wù)插入，更新，刪除 id=1 這一行。

需要注意的是：

• id 列必須為唯一索引列或主鍵列，否則上述語句加的鎖就會(huì)變成臨鍵鎖。
• 同時(shí)查詢語句必須為精準(zhǔn)匹配（=），不能為 >、<、like 等，否則也會(huì)退化成臨鍵鎖。

在通過 主鍵索引 與 唯一索引 對(duì)數(shù)據(jù)行進(jìn)行 UPDATE 操作時(shí)，也會(huì)對(duì)該行數(shù)據(jù)加記錄鎖：

-- id 列為主鍵列或唯一索引列 
UPDATE SET age = 50 WHERE id = 1;

• 記錄鎖是鎖住記錄，鎖住索引記錄，而不是真正的數(shù)據(jù)記錄。
• 如果要鎖的列沒有索引，進(jìn)行全表記錄加鎖。
• 記錄鎖也是排它 (X) 鎖，所以會(huì)阻塞其他事務(wù)對(duì)其插入、更新、刪除。

3.2 間隙鎖（Gap Locks）

間隙鎖 是 InnoDB 在 RR（可重復(fù)讀）隔離級(jí)別下為了解決 幻讀問題 時(shí)引入的鎖機(jī)制。間隙鎖是InnoDB 中行鎖的一種。

請(qǐng)務(wù)必牢記：使用間隙鎖鎖住的是一個(gè)區(qū)間，而不僅僅是這個(gè)區(qū)間中的每一條數(shù)據(jù)。

舉例來說，假如 emp 表中只有 101 條記錄，其 empid 的值分別是1, 2, …, 100, 101，下面的SQL：

SELECT * FROM emp WHERE empid > 100 FOR UPDATE

當(dāng)我們用條件檢索數(shù)據(jù)，并請(qǐng)求共享或排他鎖時(shí)，InnoDB 不僅會(huì)對(duì)符合條件的 empid 值為 101 的記錄加鎖，也會(huì)對(duì) empid 大于 101（這些記錄并不存在）的 “間隙” 加鎖。

這個(gè)時(shí)候如果你插入 empid 等于 102 的數(shù)據(jù)的，如果那邊事物還沒有提交，那你就會(huì)處于等待狀態(tài)，無法插入數(shù)據(jù)。

3.3 臨鍵鎖（Next-Key Locks）

Next-key 鎖是記錄鎖和間隙鎖的組合，它指的是加在 某條記錄以及這條記錄前面間隙上 的鎖。

也可以理解為一種特殊的間隙鎖。通過臨建鎖可以解決幻讀的問題。每個(gè)數(shù)據(jù)行上的非唯一索引列（該索引里面的值允許重復(fù)）上都會(huì)存在一把臨鍵鎖，當(dāng)某個(gè)事務(wù)持有該數(shù)據(jù)行的臨鍵鎖時(shí)，會(huì)鎖住一段 左開右閉 區(qū)間的數(shù)據(jù)。

需要強(qiáng)調(diào)的一點(diǎn)是，InnoDB 中行級(jí)鎖是基于索引實(shí)現(xiàn)的，臨鍵鎖只與非唯一索引列有關(guān)，在唯一索引列（包括主鍵列）上不存在臨鍵鎖。

假設(shè)有如下表：id 主鍵，age 普通索引。

該表中 age 列潛在的臨鍵鎖有：(-∞, 10]，(10, 24]，(24, 32]，(32, 45]，(45, +∞]。

在事務(wù) A 中執(zhí)行如下命令：

-- 根據(jù)非唯一索引列 UPDATE 某條記錄 
UPDATE table SET name = Vladimir WHERE age = 24; 

-- 或根據(jù)非唯一索引列 鎖住某條記錄 
SELECT * FROM table WHERE age = 24 FOR UPDATE;

不管執(zhí)行了上述 SQL 中的哪一句，之后如果在事務(wù) B 中執(zhí)行以下命令，則該命令會(huì)被阻塞：

INSERT INTO table VALUES(100, 26, 'tianqi');

很明顯，事務(wù) A 在對(duì) age 為 24 的列進(jìn)行 UPDATE 操作的同時(shí)，也獲取了 (10, 32] 這個(gè)區(qū)間內(nèi)的 臨鍵鎖。

這里對(duì) 記錄鎖、間隙鎖、臨鍵鎖 做一個(gè)總結(jié)：

• InnoDB 中的 行鎖 的實(shí)現(xiàn)依賴于 索引，一旦某個(gè)加鎖操作沒有使用到索引，那么該鎖就會(huì)退化為表鎖。
• 記錄鎖 存在于包括 主鍵索引 在內(nèi)的 唯一索引 中，鎖定單條索引記錄。
• 間隙鎖 存在于 非唯一索引 中，鎖定開區(qū)間范圍內(nèi)的一段間隔，它是基于 臨鍵鎖 實(shí)現(xiàn)的。
• 臨鍵鎖 存在于 非唯一索引 中，該類型的每條記錄的索引上都存在這種鎖，它是 一種特殊的間隙鎖，鎖定一段 左開右閉 的索引區(qū)間。

3.4 意向鎖

意向鎖也分為 意向共享鎖（IS） 和 意向排他鎖（IX）。

• 意向共享(IS)鎖：事務(wù)有意向?qū)Ρ碇械哪承┬屑庸蚕礞i（S鎖）

-- 事務(wù)要獲取某些行的 S 鎖，必須先獲得表的 IS 鎖。
SELECT column FROM table ... LOCK IN SHARE MODE;

• 意向排他(IX)鎖：事務(wù)有意向?qū)Ρ碇械哪承┬屑优潘i（X鎖）

 -- 事務(wù)要獲取某些行的 X 鎖，必須先獲得表的 IX 鎖。
 SELECT column FROM table ... FOR UPDATE;

首先我們要明白四點(diǎn)：

• 意向共享鎖（IS）和 意向排他鎖（IX）都是 表鎖。
• 意向鎖是一種 不與行級(jí)鎖沖突的表級(jí)鎖，這一點(diǎn)非常重要。
• 意向鎖是 InnoDB 自動(dòng)加的， 不需用戶干預(yù)。
• 意向鎖是在 InnoDB 下存在的內(nèi)部鎖，對(duì)于MyISAM 而言沒有意向鎖之說。

這里就會(huì)有疑惑，既然前面已經(jīng)有了共享鎖（S鎖）、排它鎖（X鎖）。那么為什么需要引入意向鎖呢？它能解決什么問題呢？

我們可以理解 意向鎖存在的目的 就是 為了讓 InnoDB 中的行鎖和表鎖更高效的共存。

為什么這么說，我們來舉一個(gè)例子。下面有一張表 id 是主鍵。

事務(wù) A 獲取了某一行的排他鎖，并未提交：

SELECT * FROM users WHERE id = 6 FOR UPDATE;

事務(wù) B 想要獲取 users 表的表鎖：

LOCK TABLES users READ;

因?yàn)楣蚕礞i與排他鎖互斥，所以事務(wù) B 在視圖對(duì) users 表加共享鎖的時(shí)候，必須保證：

• 當(dāng)前沒有其他事務(wù)持有 users 表的排他鎖。
• 當(dāng)前沒有其他事務(wù)持有 users 表中任意一行的排他鎖 。

為了檢測(cè)是否滿足第二個(gè)條件，事務(wù) B 必須在確保 users 表不存在任何排他鎖的前提下，去檢測(cè)表中的每一行是否存在排他鎖。很明顯這是一個(gè)效率很差的做法，但是有了意向鎖之后，情況就不一樣了：事務(wù) B 只要看表上有沒有意向共享鎖，有則說明表中有些行被共享行鎖鎖住了，因此，事務(wù) B 申請(qǐng)表的寫鎖會(huì)被阻塞。這樣是不是就高效多了。

這也解釋就應(yīng)該清楚，為什么有意向鎖這個(gè)東西存在了。我們可以舉個(gè)生活中的例子，再來理解下為什么需要存在意向鎖。

打個(gè)比方，就像有個(gè)游樂場(chǎng)，很多小朋友進(jìn)去玩，看門大爺如果要下班鎖游樂場(chǎng)的門(加表鎖)，他必須確保每個(gè)角落都要去檢查一遍，確保每個(gè)小朋友都離開了（釋放行鎖），才可以鎖門。

假設(shè)鎖門是件頻繁發(fā)生的事情，大爺就會(huì)非常崩潰。那大爺想了一個(gè)辦法，每個(gè)小朋友進(jìn)入，就把自己的名字寫在本子上，小朋友離開，就把自己的名字劃掉，那大爺就能方便掌握有沒有小朋友在游樂場(chǎng)里，不必每個(gè)角落都去尋找一遍。例子中的“小本子”，就是意向鎖，他記錄的信息并不精細(xì)，他只是提醒大爺，是否有人在屋里。

這里我們?cè)賮砜聪?共享(S)鎖、排他(X)鎖、意向共享鎖(IS)、意向排他鎖(IX) 的兼容性。

可以看出 意向鎖之間是互相兼容的。那你存在的意義是啥？

意向鎖不會(huì)為難意向鎖，也不會(huì)為難 行級(jí)排他(X) / 共享(X)鎖，它的存在是為難 表級(jí)排他(X) / 共享(X)鎖。

注意 這里的 排他(X) / 共享(S)鎖 指的都是表鎖！意向鎖不會(huì)與 行級(jí)的共享 / 排他鎖 互斥！

意向鎖與意向鎖之間永遠(yuǎn)是兼容的，因?yàn)楫?dāng)你不論加行級(jí)的 X 鎖或 S 鎖，都會(huì)自動(dòng)獲取表級(jí)的 IX 鎖或者 IS 鎖。也就是你有 10 個(gè)事務(wù)，對(duì)不同的 10 行加了行級(jí) X 鎖，那么這個(gè)時(shí)候就存在 10 個(gè) IX 鎖。

這 10 個(gè) IX 存在的作用是啥呢，就是假如這個(gè)時(shí)候有個(gè)事務(wù)，想對(duì)整個(gè)表加排它 X 鎖,那它不需要遍歷每一行是否存在 S 或 X 鎖，而是看有沒有存在 意向鎖，只要存在一個(gè)意向鎖，那這個(gè)事務(wù)就加不了表級(jí)排它(X)鎖，要等上面 10 個(gè) IX 全部釋放才行。

3.5 插入意向鎖

在講解插入意向鎖之前，先來思考一個(gè)問題？

下面有張表 id 主鍵，age 普通索引。

首先事務(wù) A 插入了一行數(shù)據(jù)，并且沒有 commit：

INSERT INTO users SELECT 4, 'Bill', 15;

隨后事務(wù) B 試圖插入一行數(shù)據(jù)：

INSERT INTO users SELECT 5, 'Louis', 16;

請(qǐng)問：

• 事務(wù) A 使用了什么鎖？
• 事務(wù) B 是否會(huì)被事務(wù) A 阻塞？

插入意向鎖是在插入一條記錄行前，由 INSERT 操作產(chǎn)生的一種間隙鎖。

該鎖用以表示插入意向，當(dāng)多個(gè)事務(wù)在同一區(qū)間（gap）插入位置不同的多條數(shù)據(jù)時(shí)，事務(wù)之間不需要互相等待。

假設(shè)存在兩條值分別為 4 和 7 的記錄，兩個(gè)不同的事務(wù)分別試圖插入值為 5 和 6 的兩條記錄，每個(gè)事務(wù)在獲取插入行上獨(dú)占的（排他）鎖前，都會(huì)獲?。?，7 ] 之間的間隙鎖，但是因?yàn)閿?shù)據(jù)行之間并不沖突，所以兩個(gè)事務(wù)之間并不會(huì)產(chǎn)生沖突（阻塞等待）。

總結(jié)來說，插入意向鎖 的特性可以分成兩部分：

• 插入意向鎖是 一種特殊的間隙鎖 —— 間隙鎖可以鎖定開區(qū)間內(nèi)的部分記錄。
• 插入意向鎖之間互不排斥，所以即使多個(gè)事務(wù)在同一區(qū)間插入多條記錄，只要記錄本身（主鍵、唯一索引）不沖突，那么事務(wù)之間就不會(huì)出現(xiàn)沖突等待。

雖然插入意向鎖中含有意向鎖三個(gè)字，但是它并不屬于意向鎖而屬于間隙鎖，因?yàn)橐庀蜴i是表鎖，而插入意向鎖是行鎖。

現(xiàn)在我們可以回答開頭的問題了：

• 使用插入意向鎖與記錄鎖。
• 事務(wù) A 不會(huì)阻塞事務(wù) B。

為什么不用間隙鎖？

如果只是使用普通的間隙鎖會(huì)怎么樣呢？我們?cè)诳词聞?wù) A，其實(shí)它一共獲取了 3 把鎖：

• id 為 4 的記錄行的記錄鎖。
• age 區(qū)間在（10，15 ] 的間隙鎖。
• age 區(qū)間在（15，20 ] 的間隙鎖。

最終，事務(wù) A 插入了該行數(shù)據(jù)，并鎖住了（10，20 ] 這個(gè)區(qū)間。

隨后事務(wù) B 試圖插入一行數(shù)據(jù)：

INSERT INTO users SELECT 5, 'Louis', 16;

因?yàn)?16 位于（15，20 ] 區(qū)間內(nèi)，而該區(qū)間內(nèi)又存在一把間隙鎖，所以事務(wù) B 別說想申請(qǐng)自己的間隙鎖了，它甚至不能獲取該行的記錄鎖，自然只能乖乖的等待事務(wù) A 結(jié)束，才能執(zhí)行插入操作。

很明顯，這樣做事務(wù)之間將會(huì)頻發(fā)陷入阻塞等待，插入的并發(fā)性非常之差。這時(shí)如果我們?cè)偃セ叵胛覀儎倓傊v過的插入意向鎖，就不難發(fā)現(xiàn)它是如何優(yōu)雅的解決了并發(fā)插入的問題。

總結(jié)

• InnoDB 在 RR 的事務(wù)隔離級(jí)別下，使用插入意向鎖來控制和解決并發(fā)插入。
• 插入意向鎖是 一種特殊的間隙鎖。
• 插入意向鎖在鎖定區(qū)間相同但記錄行本身不沖突的情況下互不排斥。

四、樂觀鎖、悲觀鎖

4.1 定義

樂觀鎖，顧名思義，樂觀鎖就是持比較樂觀態(tài)度的鎖。就是在操作數(shù)據(jù)時(shí)非常樂觀，認(rèn)為別的線程不會(huì)同時(shí)修改數(shù)據(jù)，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷在此期間別的線程有沒有更新過這個(gè)數(shù)據(jù)。

悲觀鎖，就是持悲觀態(tài)度的鎖。就在操作數(shù)據(jù)時(shí)比較悲觀，每次去拿數(shù)據(jù)的時(shí)候認(rèn)為別的線程也會(huì)同時(shí)修改數(shù)據(jù)，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別的線程想拿到這個(gè)數(shù)據(jù)就會(huì)阻塞直到它拿到鎖。

4.2 如何理解？

舉個(gè)例子，有時(shí)候我們上公共廁所的時(shí)候要排隊(duì)。如果你蹲馬桶的時(shí)候開著門，外面有人排著隊(duì)看著你。你會(huì)這么做嗎？當(dāng)然，如果在自己家里，有可能會(huì)這么干，這就是樂觀鎖。雖然，能進(jìn)到房間，但是有人占著坑位，該排隊(duì)還是得排隊(duì)。 比如數(shù)據(jù)庫提供的類似于 write_condition 機(jī)制，Java API 并發(fā)工具包下面的原子變量類就是使用了樂觀鎖的 CAS（Compare and Swap，比較并交換） 來實(shí)現(xiàn)的。

悲觀鎖就不同了，就相當(dāng)于是進(jìn)房間之后，第一件事就是把門鎖上，那在門外排隊(duì)等候的人不知道里面發(fā)生了什么，又著急但是又只能干等著，這就是悲觀鎖。比如行鎖、表鎖、讀鎖、寫鎖，都是在操作之前先上鎖，Java API 中的 synchronized 和 ReentrantLock 等獨(dú)占鎖都是悲觀鎖思想的實(shí)現(xiàn)。

4.3 應(yīng)用場(chǎng)景

根據(jù)前面對(duì)兩種鎖的介紹，總結(jié)一下兩種鎖的應(yīng)用場(chǎng)景：

• 樂觀鎖，它適用于讀多寫少的情況，也就是說減少操作沖突，這樣可以省去鎖競(jìng)爭(zhēng)的開銷，提高系統(tǒng)的吞吐量。
• 而悲觀鎖呢，它適用于寫多讀少的情況。因?yàn)?，如果還使用樂觀鎖的話，會(huì)經(jīng)常出現(xiàn)操作沖突，這樣會(huì)導(dǎo)致應(yīng)用層會(huì)不斷地 Retry，反而會(huì)降低系統(tǒng)性能。

思考一刻：你認(rèn)為秒殺場(chǎng)景下，并發(fā)下單和支付應(yīng)該使用什么鎖？

• 使用樂觀鎖并發(fā)下單
• 使用悲觀鎖發(fā)起支付

參考資料

【1】一文詳解 MySQL 的鎖機(jī)制
【2】什么是樂觀鎖，什么是悲觀鎖 ？文章來源地址http://www.zghlxwxcb.cn/news/detail-443025.html

到了這里，關(guān)于【數(shù)據(jù)庫】MySQL中的鎖機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！