面試官：談談MySQL鎖機制

作者：玄武后端技術棧 2025-10-31 02:00:00

數據庫 MySQL

從鎖的類型角度，MySQL 分為共享鎖（S 鎖，讀鎖）和排他鎖（X 鎖，寫鎖）。共享鎖允許多個事務同時讀取同一資源，但不允許寫入；排他鎖則是獨占式的，持有排他鎖的事務可以讀寫數據，其他事務無法獲取任何鎖。

MySQL 的鎖機制是保證數據庫并發訪問時數據一致性和完整性的核心手段。

從鎖的粒度來說，MySQL 支持表級鎖、行級鎖和頁級鎖，其中 InnoDB 主要使用行級鎖來提高并發性能。

在實際應用中，InnoDB 引擎還實現了意向鎖（IS 鎖和 IX 鎖），這是表級鎖，是一個標識，用于表明事務稍后要獲取的行鎖類型，主要是為了提高加表級鎖時的效率，避免逐行檢查。

為了解決幻讀問題，InnoDB 引入了間隙鎖（Gap Lock）和臨鍵鎖（Next-Key Lock）。間隙鎖鎖定索引記錄之間的間隙，防止其他事務在該間隙插入數據；臨鍵鎖是行鎖和間隙鎖的組合，鎖定記錄本身及其前面的間隙。

從鎖的實現層面，InnoDB 采用兩階段鎖協議，事務執行過程中隨時可以加鎖，但所有鎖只有在事務提交或回滾時才會統一釋放。這個機制雖然簡單，但可能導致死鎖問題，MySQL 通過死鎖檢測和超時機制來處理死鎖。

另外，還有樂觀鎖和悲觀鎖的概念。悲觀鎖認為并發沖突概率高，每次操作都加鎖；樂觀鎖則相反，通過版本號或 CAS 機制在提交時檢查沖突。MySQL 的鎖機制本質上是悲觀鎖的實現，而樂觀鎖需要在應用層實現。

一、鎖的基本概念：為什么需要鎖？

我們先理解一個根本問題：為什么數據庫需要鎖？

想象一個電商場景：雙十一零點，成千上萬的用戶同時搶購一件商品，庫存只有 100 件。如果沒有鎖機制，可能出現這樣糟糕的情況：

張三查詢庫存，看到還有 1 件，準備下單。與此同時，李四也查詢庫存，也看到還有 1 件。然后兩人幾乎同時提交訂單，系統扣減庫存。結果本來只有 1 件商品，卻賣出去了 2 件，出現了超賣的問題，這就是典型的并發問題。

鎖機制的本質就是通過串行化某些操作來保證數據的一致性。當張三正在處理庫存扣減時，系統會給這條庫存記錄加鎖，李四只能等待，直到張三完成操作釋放鎖后，李四才能繼續。

但是，鎖的代價是降低并發性能。如果所有操作都串行化，那數據庫的并發能力就太差了。因此，MySQL 就設計了一套精細化的鎖機制，在保證數據一致性的前提下，盡可能的去提高并發性能。

二、鎖的粒度

MySQL 支持多種鎖粒度

2.1 表級鎖

表級鎖是最簡單的鎖實現方式，直接鎖定整張表。當一個事務獲取表級寫鎖時，其他事務無法讀寫該表；獲取表級讀鎖時，其他事務可以讀但不能寫。

表級鎖的優點是開銷小，加鎖快，不會出現死鎖。但缺點也很明顯：鎖的粒度太大，并發度低。比如一個表有 100 萬條記錄，某個事務只想更新其中 1 條，卻要鎖住整張表，其他 99 萬 9999 條記錄都被"連累"了。

MySQL中的MyISAM 存儲引擎就是使用表級鎖。這也是為什么 MyISAM 不適合高并發寫入場景的根本原因。

2.2 行級鎖

行級鎖是 InnoDB 的核心特性，它只鎖定需要操作的數據行，其他行不受影響。還是剛才的例子，如果使用行級鎖，一個事務更新第 1 條記錄時，另一個事務完全可以同時更新第 2 條記錄，互不干擾。

行級鎖的并發度高，但開銷也更大。每加一個鎖都需要消耗內存，維護鎖的數據結構也需要額外的 CPU 開銷。而且，行級鎖可能導致死鎖問題。

2.3 頁級鎖

頁級鎖是 BDB 存儲引擎使用的鎖機制，鎖定的是數據頁（通常是 16KB）。它介于表級鎖和行級鎖之間，既不會像表級鎖那樣粒度過粗，也不會像行級鎖那樣開銷過大。但頁級鎖的實現復雜度較高，而且可能出現鎖沖突的概率介于二者之間。

由于 BDB 引擎已經不再主流，BDB存儲引擎在MySQL 5.1版本后被逐步棄用。

三、鎖的類型

在確定了鎖的粒度后，我們還需要區分鎖的類型。InnoDB 主要使用兩種基本鎖類型：

3.1 共享鎖（Shared Lock，S 鎖）

共享鎖，顧名思義，是可以"共享"的鎖。當一個事務對某行數據加上共享鎖后，其他事務也可以對該行加共享鎖，大家一起讀取數據。但是，任何事務都不能對該行加排他鎖，也就是不能修改數據。

比如舉個例子：多個人同時看一本書沒問題，但如果有人要修改書的內容，就必須等所有人都看完、放下書之后才能開始修改。

在 SQL 中，可以通過以下方式顯式加共享鎖：

執行 SELECT ... LOCK IN SHARE MODE 語句時，會對讀取的行加共享鎖。但這種用法比較少見，通常用在需要確保讀取后到事務提交期間數據不被修改的場景。

3.2 排他鎖（Exclusive Lock，X 鎖）

排他鎖是獨占式的鎖。當一個事務對某行數據加上排他鎖后，其他事務既不能加共享鎖（不能讀），也不能加排他鎖（不能寫）。只有持有排他鎖的事務可以讀寫該行數據。

再用上面書的例子，比如當有人要修改書的內容時，他必須獨占這本書，其他人既不能看也不能改。

執行 UPDATE、DELETE、INSERT 語句時，MySQL 會自動對涉及的行加排他鎖。也可以通過 SELECT ... FOR UPDATE顯式加排他鎖。

3.3 鎖的兼容性矩陣

理解共享鎖和排他鎖的關鍵是掌握它們的兼容性：

S 鎖 + S 鎖：兼容。多個事務可以同時持有同一行的共享鎖。
S 鎖 + X 鎖：不兼容。如果一行已經被加了共享鎖，其他事務無法加排他鎖；反之亦然。
X 鎖 + X 鎖：不兼容。一行只能被一個事務加排他鎖。

這個矩陣可以總結為：讀讀可以并行，讀寫互斥，寫寫互斥。

四、意向鎖：表級鎖與行級鎖的協調者

要理解意向鎖，我們先看一個問題：

假設事務 A 對某個表的第 1000 行加了行級排他鎖。此時事務 B 想對整張表加表級排他鎖，MySQL 如何判斷能否加鎖成功？

最直觀的方法是：遍歷表的所有行，檢查是否有行級鎖。但這個開銷太大了，如果表有幾百萬行，每次加表級鎖都要掃描一遍，性能會急劇下降。

意向鎖就是為了解決這個問題而設計的。它是一種表級鎖，分為兩種：

4.1 意向共享鎖（IS 鎖）

當一個事務想要對表中的某些行加共享鎖時，必須先對該表加意向共享鎖。意向共享鎖表達的意思是："我打算對這張表的某些行加共享鎖"。

4.2 意向排他鎖（IX 鎖）

當一個事務想要對表中的某些行加排他鎖時，必須先對該表加意向排他鎖。意向排他鎖表達的意思是："我打算對這張表的某些行加排他鎖"。

4.3 意向鎖的作用機制

有了意向鎖，前面的問題就簡單了：

事務 A 對第 1000 行加排他鎖時，會先對該表加意向排他鎖（IX 鎖）
事務 B 想對整張表加表級排他鎖時，只需檢查該表是否有意向鎖
發現有 IX 鎖，說明表中某些行已被加鎖，無法加表級排他鎖，事務 B 等待

這樣就避免了逐行掃描的開銷。意向鎖之間是兼容的，因為它們只是"意向"，真正的沖突在行級鎖層面解決。

意向鎖的兼容性：

IS 鎖與 IS 鎖、IX 鎖都兼容
IX 鎖與 IS 鎖、IX 鎖都兼容
表級 S 鎖與 IS 鎖兼容，但與 IX 鎖不兼容
表級 X 鎖與任何意向鎖都不兼容

意向鎖對開發者是透明的，由 MySQL 自動管理，我們通常不需要顯式操作。但理解它的機制有助于我們更好地理解 InnoDB 的鎖體系。

五、記錄鎖、間隙鎖與臨鍵鎖：解決幻讀的利器

行級鎖聽起來很簡單，但 InnoDB 的行級鎖實際上包含多種細分類型。這些鎖的設計主要是為了在不同隔離級別下解決不同的并發問題，特別是幻讀問題。

5.1 記錄鎖（Record Lock）

記錄鎖是最基礎的行級鎖，它鎖定的是索引記錄本身。注意，這里強調"索引記錄"，因為 InnoDB 的鎖是加在索引上的，而不是直接加在數據行上。

如果查詢條件沒有使用索引，InnoDB 會使用隱藏的主鍵索引（聚簇索引）來加鎖。如果是通過二級索引查詢，會先鎖定二級索引記錄，然后再鎖定對應的主鍵索引記錄。

舉個例子：表中有一條記錄 id=10，當執行 UPDATE users SET name='張三' WHERE id=10 時，會對 id=10 這條索引記錄加記錄鎖。

5.2 間隙鎖（Gap Lock）

間隙鎖是 InnoDB 在可重復讀隔離級別下為了防止幻讀而引入的鎖機制。它鎖定的不是記錄本身，而是索引記錄之間的"間隙"。

假設表中有三條記錄，id 分別是 10、20、30。那么存在以下間隙：

負無窮到 10 之前 (-∞，10)
10 到 20 之間（10，20）
20 到 30 之間（20，30）
30 到正無窮之后 (30，+∞)

當執行 SELECT * FROM users WHERE id > 10 AND id < 20 FOR UPDATE 時，即使范圍內沒有記錄，InnoDB 也會對這個間隙加鎖，防止其他事務在這個范圍內插入新記錄。

間隙鎖的特點：

只在可重復讀隔離級別下生效。在讀已提交隔離級別下，間隙鎖會被禁用，只使用記錄鎖。
間隙鎖之間不沖突。多個事務可以同時持有同一個間隙的間隙鎖，因為間隙鎖的唯一目的是防止插入，而不是防止讀寫已有記錄。
間隙鎖會降低并發性能。它鎖定的范圍可能很大，會阻塞其他事務的插入操作。

5.3 臨鍵鎖（Next-Key Lock）

臨鍵鎖是記錄鎖和間隙鎖的組合，它鎖定的是一個左開右閉的區間。這是 InnoDB 在可重復讀隔離級別下的默認行級鎖。

還是剛才的例子，表中有 id 為 10、20、30 的記錄。當執行范圍查詢時，可能會加上以下臨鍵鎖：

(-∞, 10]
(10, 20]
(20, 30]
(30, +∞]

臨鍵鎖既鎖定記錄本身，又鎖定記錄前面的間隙，能夠同時防止幻讀和不可重復讀。

5.4 為什么需要這么復雜的鎖？

這些鎖的設計都是為了在不同場景下平衡性能和一致性：

場景一：點查詢

執行 SELECT * FROM users WHERE id = 10 FOR UPDATE，只需要記錄鎖，鎖定 id=10 這一條記錄即可。

場景二：范圍查詢

執行 SELECT * FROM users WHERE id >= 10 AND id <= 20 FOR UPDATE，需要使用臨鍵鎖，鎖定區間內的所有記錄以及區間本身，防止幻讀。

場景三：不存在的記錄

執行 SELECT * FROM users WHERE id = 15 FOR UPDATE，如果 id=15 不存在，會對（10， 20）這個間隙加間隙鎖，防止其他事務插入 id=15 的記錄。

六、鎖與事務隔離級別的關系

MySQL 的鎖機制與事務隔離級別緊密相關。不同的隔離級別使用不同的鎖策略來保證數據一致性。

6.1 讀未提交（Read Uncommitted）

這是最低的隔離級別，幾乎不使用鎖。讀操作不加鎖，可以讀到其他事務未提交的數據（臟讀）。寫操作會加排他鎖，但只鎖定記錄本身。

這個級別性能最好，但一致性最差，實際應用中幾乎不使用。

6.2 讀已提交（Read Committed）

在這個級別下，讀操作使用快照讀（MVCC），不加鎖。寫操作會加記錄鎖，但不會使用間隙鎖。

這意味著可以避免臟讀，但無法避免不可重復讀和幻讀。比如：

事務 A 第一次查詢 id=10 的記錄，看到 name='張三'
事務 B 更新這條記錄為 name='李四'并提交
事務 A 第二次查詢 id=10 的記錄，看到 name='李四'

同一個事務中兩次讀取的結果不一致，這就是不可重復讀。

6.3 可重復讀（Repeatable Read）

這是 InnoDB 的默認隔離級別。在這個級別下：

讀操作使用快照讀（MVCC），讀取的是事務開始時的數據快照
寫操作使用臨鍵鎖，既鎖定記錄本身，也鎖定間隙

通過 MVCC，同一個事務中多次讀取同一條記錄，看到的結果是一致的，解決了不可重復讀問題。通過間隙鎖，防止其他事務在范圍內插入新記錄，解決了幻讀問題。

但需要注意，快照讀只能防止部分幻讀。如果使用當前讀（如 SELECT ... FOR UPDATE），仍可能出現幻讀，此時就需要依靠間隙鎖來解決。

6.4 串行化（Serializable）

這是最高的隔離級別，所有讀操作都會加共享鎖，寫操作加排他鎖，事務之間完全串行執行。這個級別保證了最強的一致性，但性能最差，實際應用中很少使用。

6.5 隔離級別選擇的權衡

讀未提交：性能好，一致性差，幾乎不用
讀已提交：Oracle、SQL Server 的默認級別，適合對一致性要求不高的場景
可重復讀：MySQL 的默認級別，平衡了性能和一致性，是最常用的選擇
串行化：一致性最強，性能最差，只在特殊場景使用

七、兩階段鎖協議：鎖的生命周期

InnoDB 采用兩階段鎖協議（Two-Phase Locking，2PL）來管理鎖的生命周期。

7.1 什么是兩階段鎖協議？

兩階段鎖協議將事務分為兩個階段：

加鎖階段（Growing Phase）：事務可以獲取鎖，但不能釋放鎖。在這個階段，事務隨著執行逐步獲取需要的各種鎖。

釋放鎖階段（Shrinking Phase）：事務可以釋放鎖，但不能再獲取新鎖。一旦事務開始釋放任何一個鎖，就進入這個階段。

在 InnoDB 中，實現相對簡化：事務執行過程中隨時可以加鎖，但所有鎖只在事務提交或回滾時才統一釋放。這保證了事務的隔離性。

7.2 鎖的持有時間與性能

兩階段鎖協議有一個重要的性能含義：鎖的持有時間從加鎖開始，一直到事務結束。

假設一個事務需要執行以下操作：

更新用戶表中的記錄（加鎖）
執行一些復雜的業務邏輯計算
更新訂單表中的記錄（加鎖）
提交事務（釋放所有鎖）

在這個過程中，第 1 步獲取的鎖會一直持有到第 4 步，即使第 2 步和第 3 步并不需要這個鎖。

這啟發我們一個重要的優化原則：盡量縮短事務的執行時間，減少鎖的持有時間，避免長事務。具體做法包括：

不要在事務中執行復雜的業務邏輯計算
不要在事務中進行遠程調用
將不需要事務保護的操作移到事務外面

八、死鎖

8.1 什么是死鎖？

死鎖是指兩個或多個事務互相等待對方釋放鎖，導致所有事務都無法繼續執行的狀態。

經典的死鎖場景：

事務 A 鎖定了資源 1，準備鎖定資源 2
事務 B 鎖定了資源 2，準備鎖定資源 1
事務 A 等待事務 B 釋放資源 2，事務 B 等待事務 A 釋放資源 1
雙方都在等待，誰也無法繼續

8.2 死鎖的四個必要條件

死鎖的發生需要同時滿足四個條件：

互斥條件：資源只能被一個事務占用，其他事務必須等待。這是鎖的本質特性，無法消除。

持有并等待：事務持有至少一個資源，并等待獲取其他資源。這也是兩階段鎖協議的必然結果。

不可剝奪：資源不能被強行奪走，只能由持有者主動釋放。MySQL 的鎖機制也具有這個特性。

循環等待：存在一個資源等待環路，每個事務都在等待環路中下一個事務持有的資源。這是死鎖的關鍵特征。

只有同時滿足這四個條件，才會發生死鎖。破壞任何一個條件，就能避免死鎖。

8.3 如何避免死鎖？

雖然 MySQL 可以自動檢測和處理死鎖，但頻繁的死鎖會嚴重影響性能。我們應該從設計層面就盡量避免死鎖：

按相同順序訪問資源：如果所有事務都按照相同的順序獲取鎖，就不會形成循環等待。比如，總是先鎖用戶表，再鎖訂單表，而不是有時先鎖訂單表。

縮短事務持續時間：事務執行時間越短，持有鎖的時間就越短，發生死鎖的概率就越低。

降低事務隔離級別：如果業務允許，可以使用讀已提交隔離級別，避免使用間隙鎖，減少鎖沖突。

合理設計索引：確保查詢都能走索引，避免全表掃描導致大量加鎖。

大事務拆分為小事務：不要在一個事務中處理過多數據，可以分批處理，減少鎖的持有時間。

圖片

九、悲觀鎖與樂觀鎖思想

除了 MySQL 內置的鎖機制，還有兩種重要的并發控制思想：悲觀鎖和樂觀鎖。這兩種思想代表了對待并發沖突的不同態度。

9.1 悲觀鎖：先鎖后用

悲觀鎖的思想是：假設并發沖突經常發生，所以每次操作數據時都先加鎖，確保只有自己能訪問，操作完成后再釋放鎖。

MySQL 的鎖機制本質上就是悲觀鎖的實現。當執行 SELECT ... FOR UPDATE 時，就是在使用悲觀鎖：先把數據鎖住，確保別人不能修改，然后再進行操作。

悲觀鎖的特點：

實現簡單，由數據庫保證并發安全
性能開銷較大，會阻塞其他事務
適合并發沖突頻繁的場景
可能導致死鎖

9.2 樂觀鎖：先用后驗

樂觀鎖的思想是：假設并發沖突很少發生，所以不加鎖，直接操作數據。但在提交時檢查是否有沖突，如果有沖突就放棄操作并重試。

樂觀鎖通常通過版本號或時間戳來實現。每條記錄包含一個版本號字段，每次更新時：

讀取記錄及其版本號，比如版本號為 5
在本地完成業務邏輯計算
提交更新時，檢查版本號是否仍為 5
如果仍為 5，說明沒有沖突，更新數據并將版本號改為 6
如果不是 5，說明有其他事務已經修改過，本次更新失敗，需要重試

樂觀鎖的特點：

不需要數據庫鎖，不會阻塞其他事務
性能好，適合讀多寫少的場景
實現相對復雜，需要應用層處理沖突
需要額外的版本號字段

9.3 如何選擇？

選擇悲觀鎖還是樂觀鎖，取決于具體的業務場景：

使用悲觀鎖的場景：

寫操作頻繁，沖突概率高
每次沖突的代價很高（比如涉及復雜計算）
需要強一致性保證
典型場景：秒殺、庫存扣減、賬戶余額更新

使用樂觀鎖的場景：

讀操作遠多于寫操作
沖突概率低
可以容忍偶爾的重試
典型場景：用戶信息修改、文章編輯、商品詳情更新

實際項目中，往往是兩者結合使用。對于核心的高沖突資源使用悲觀鎖，對于邊緣的低沖突資源使用樂觀鎖。

十、鎖優化

最后我們來聊聊實際開發中如何優化鎖的使用，避免鎖相關的性能問題。

10.1 索引優化：減少鎖的范圍

InnoDB 的鎖是加在索引上的，如果沒有合適的索引，查詢會走全表掃描，導致鎖定大量無關的記錄，甚至退化成表級鎖。

反例：沒有索引的更新

UPDATE users SET status = 1 WHERE name = '張三';

如果 name 字段沒有索引，這條 SQL 會掃描全表，鎖定所有記錄。

正例：有索引的更新

-- 在name字段上建立索引
CREATE INDEX idx_name ON users(name);

UPDATE users SET status = 1 WHERE name = '張三';

此時只會鎖定 name='張三'的記錄。

10.2 盡量使用主鍵或唯一索引

使用主鍵或唯一索引進行查詢，可以精確定位記錄，避免加不必要的間隙鎖。

如果 WHERE 條件是非唯一索引，可能會鎖定多條記錄以及它們之間的間隙。如果 WHERE 條件是主鍵或唯一索引，通常只鎖定一條記錄，不會加間隙鎖。

10.3 減小事務范圍

事務越大，持有鎖的時間越長，發生鎖沖突的概率越高。應該：

只在真正需要事務保護的地方使用事務
不要在事務中執行耗時的操作（如遠程調用、復雜計算）
將大事務拆分為多個小事務

10.4 避免在循環中逐條操作

反例：在循環中逐條更新

-- 偽代碼
for each userId in userList:
    UPDATE users SET score = score + 1 WHERE id = userId;

每次更新都是一個單獨的事務，效率低，而且容易導致死鎖。

正例：批量更新

UPDATE users SET score = score + 1 WHERE id IN (1, 2, 3, 4, 5);

一次更新多條記錄，減少事務數量和鎖等待時間。

10.5 合理設置事務隔離級別

不是所有場景都需要可重復讀隔離級別。如果業務可以容忍不可重復讀，可以使用讀已提交隔離級別，避免間隙鎖，提高并發性能。

特別是在高并發的互聯網應用中，很多公司都選擇讀已提交作為默認隔離級別。

10.6 監控和診斷鎖問題

當遇到性能問題時，可以使用以下方法診斷鎖相關問題：

查看當前鎖等待情況：

SELECT * FROM information_schema.innodb_locks;
SELECT * FROM information_schema.innodb_lock_waits;

查看最近的死鎖信息：

SHOW ENGINE INNODB STATUS;

這個命令會顯示最近一次死鎖的詳細信息，包括涉及的事務、持有的鎖、等待的鎖等，對于分析死鎖原因非常有幫助。

責任編輯：武曉燕來源：玄武后端技術棧

MySQL 鎖機制共享鎖