京東面試官揪著問的 InnoDB如何用MVCC和Next-Key Lock實現RR隔離？看完頓悟！
本文將不僅詳細解釋每種隔離級別的定義和現象，更會深入 InnoDB 存儲引擎層，探討其背后的多版本并發控制（MVCC）和鎖機制是如何協同工作來實現這些隔離級別的。
什么是事務 ACID
在深入隔離級別之前，我們必須先統一共識：什么是事務？為什么需要它？
事務是數據庫操作的一個最小邏輯工作單元，其內的所有操作要么全部成功，要么全部失敗。一個經典的例子就是銀行轉賬：從 A 賬戶扣款和向 B 賬戶加款，這兩個操作必須作為一個整體，不能分割。
為了確保事務的可靠性和數據的一致性，數據庫系統必須滿足 ACID 屬性：
- 原子性 (Atomicity)： 事務是一個不可分割的整體，就像原子一樣。它要么全部完成，要么全部不完成，不存在中間狀態。InnoDB 通過Undo Log來實現原子性。如果事務失敗，Undo Log 會將已經修改的數據恢復到事務開始前的狀態。
- 一致性 (Consistency) ： 事務的執行必須使數據庫從一個一致性狀態變換到另一個一致性狀態。一致性是應用的最終追求，原子性、隔離性和持久性都是為實現一致性而存在的。例如，轉賬前后，兩個賬戶的總金額必須保持不變。
- 隔離性 (Isolation) ： 這是我們今天討論的重點。多個并發事務對數據進行修改和訪問時，數據庫系統必須提供一種機制來防止事務間的相互干擾，使得各個事務感覺不到其他事務在并發執行。隔離級別就是用來定義這種“隔離”的嚴格程度的。
- 持久性 (Durability) ： 一旦事務提交，其對數據的修改就是永久性的，即使系統發生故障也不會丟失。InnoDB 通過Redo Log來實現持久性。修改數據時，首先會寫入 Redo Log，再在合適的時間點刷寫到磁盤數據文件。即使系統崩潰，也能通過 Redo Log 恢復已提交的事務。
隔離性的挑戰： 完全隔離（串行化執行）固然安全，但會極大限制數據庫的并發處理能力，導致性能急劇下降。因此，數據庫系統提供了多種隔離級別，讓開發者可以在性能和數據一致性之間進行權衡。
并發事務并發的三個問題
在介紹隔離級別之前，我們必須先了解如果不進行任何隔離控制，并發事務會引發哪些問題。隔離級別本質上就是為了解決這些問題而存在的。
臟讀 (Dirty Read)
一個事務讀到了另一個未提交事務修改的數據。如果另一個事務中途回滾，那么第一個事務讀到的數據就是“臟”的、無效的。
示例：
- 事務 A 將賬戶余額從 100 元修改為 200 元（但未提交）。
- 此時事務 B 讀取余額，得到了 200 元這個結果。
- 事務 A 因某種原因回滾，余額恢復為 100 元。
- 事務 B 之后的操作都是基于錯誤的“200 元”余額進行的。
圖片
不可重復讀 (Non-Repeatable Read)
一個事務內，兩次讀取同一個數據項，得到了不同的結果。重點在于另一個已提交事務對數據進行了修改（UPDATE）。
示例：
- 事務 A 第一次讀取賬戶余額為 100 元。
- 此時事務 B 提交了修改，將余額更新為 150 元。
- 事務 A 再次讀取余額，得到了 150 元。兩次讀取結果不一致。
幻讀 (Phantom Read)
一個事務內，兩次執行同一個查詢，返回的結果集行數不同。重點在于另一個已提交事務對數據進行了增刪（INSERT/DELETE），像產生了幻覺一樣。
示例：
- 事務 A 第一次查詢年齡小于 30 歲的員工，返回了 10 條記錄。
- 此時事務 B 提交了一個新操作，插入了一名 25 歲的員工記錄。
- 事務 A 再次執行相同的查詢，返回了 11 條記錄。
不可重復讀 vs 幻讀：
- 不可重復讀針對的是某一行數據的值被修改（UPDATE）。
- 幻讀針對的是結果集的行數發生變化（INSERT/DELETE）。
SQL 標準下的四種事務隔離級別
為了解決上述問題，SQL 標準定義了四種隔離級別，嚴格程度從低到高。級別越高，能解決的問題越多，但并發性能通常越低。
隔離級別 | 臟讀 | 不可重復讀 | 幻讀 |
讀未提交 (Read Uncommitted) | ? 可能 | ? 可能 | ? 可能 |
讀已提交 (Read Committed) | ? 避免 | ? 可能 | ? 可能 |
可重復讀 (Repeatable Read) | ? 避免 | ? 避免 | ? 可能 |
串行化 (Serializable) | ? 避免 | ? 避免 | ? 避免 |
注意： 在 MySQL 的 InnoDB 引擎中，通過 Next-Key Locking 技術，在可重復讀（Repeatable Read） 隔離級別下就已經可以避免絕大部分的幻讀現象。這是 MySQL 對標準隔離級別的增強，也是其默認使用該級別的重要原因。
深入 InnoDB 的 MVCC 與鎖機制
MySQL 的服務層負責事務管理，確保在執行一系列操作時，滿足原子性、一致性、隔離性和持久性這四個特性。事務管理涉及的主要功能包括：
- 事務隔離級別：MySQL 支持四個事務隔離級別：讀未提交、讀已提交、可重復讀和串行化。這些隔離級別分別定義了事務間數據訪問的隔離程度，用于防止臟讀、不可重復讀和幻讀。
- 鎖管理：在事務過程中，可能需要對數據加鎖，以確保數據的一致性。MySQL 支持的鎖類型包括共享鎖、排它鎖、意向鎖、行鎖、表鎖等。
- Undo 日志：服務層通過 Undo 日志實現了事務回滾操作，當事務執行中途出現異常或用戶發出回滾請求時，可以通過 Undo 日志回滾數據到事務開始前的狀態。
- Redo 日志：為了保證事務的持久性。
要理解不同隔離級別是如何實現的，我們必須揭開 InnoDB 的兩大核心法寶：多版本并發控制 (MVCC) 和 鎖 (Locking) 。
MVCC： snapshot vs current
MVCC 的核心思想是為每一行數據維護多個版本（通常是兩個），通過某個時間點的“快照”（Snapshot）來讀取數據，從而避免加鎖帶來的性能損耗，實現非阻塞的讀操作。
InnoDB 為每行記錄隱式地添加了三個字段：
DB_TRX_ID（6 字節）： 最近一次修改該行數據的事務 ID。DB_ROLL_PTR（7 字節）： 回滾指針，指向該行數據在 Undo Log 中的上一個歷史版本。DB_ROW_ID（6 字節）： 行標識（隱藏的主鍵，如果表沒有主鍵）。
關鍵概念：ReadView在 MVCC 中，事務在執行快照讀（普通的SELECT語句）時會生成一個一致性視圖，即ReadView。ReadView 是 InnoDB 實現 MVCC 的核心數據結構，它包含：
m_ids：生成 ReadView 時活躍的事務 ID 列表min_trx_id：活躍事務中的最小 IDmax_trx_id：下一個將被分配的事務 IDcreator_trx_id：創建該 ReadView 的事務 ID
通過 ReadView，InnoDB 可以判斷某個數據版本對當前事務是否可見。
數據可見性規則： 當一行數據被訪問時，InnoDB 會遍歷其版本鏈（通過DB_ROLL_PTR指針），并應用以下規則來判斷哪個版本對當前事務是可見的：
- 如果數據版本的
trx_id<min_trx_id，說明該版本在 ReadView 創建前已提交，可見。 - 如果數據版本的
trx_id>=max_trx_id，說明該版本在 ReadView 創建后才開啟，不可見。 - 如果
min_trx_id<=trx_id<max_trx_id，則需判斷trx_id是否在m_ids中：
如果在，說明創建 ReadView 時該事務仍活躍，其修改未提交，不可見。
如果不在，說明創建 ReadView 時該事務已提交，可見。
- 如果當前記錄的事務 ID 等于
creator_trx_id，說明是本事務自己修改的，可見。
鎖機制
MVCC 主要解決了“讀”的并發問題，而“寫”（INSERT, UPDATE, DELETE）依然需要通過加鎖來保證數據正確性。
- 共享鎖 (S Lock)： 允許事務讀一行數據。其他事務可以同時獲取共享鎖，但不能獲取排他鎖。
- 排他鎖 (X Lock)： 允許事務更新或刪除一行數據。其他事務無法獲取該行的任何鎖。
此外，InnoDB 還引入了意向鎖（Intention Locks），是一種表級鎖，用來表示事務稍后會對表中的某一行加上哪種類型的鎖（共享或排他）。目的是為了更高效地判斷表級鎖沖突。
圖片
各級別詳解與 InnoDB 實現剖析
現在我們結合 MVCC 和鎖，來看看每個隔離級別在 InnoDB 中是如何具體工作的。
1. 讀未提交 (Read Uncommitted)
在讀未提交級別下，InnoDB 幾乎不進行隔離控制，事務可以直接讀取數據頁上的最新值，無論其他事務是否已提交。
- 實現原理： 幾乎不加讀鎖。一個事務可以直接看到其他未提交事務修改后的最新值。它直接讀取數據頁的最新版本，完全無視 MVCC 和 Undo Log 版本鏈。
- 問題： 所有并發問題都無法避免。
- 應用場景： 幾乎沒有使用場景，除非你完全不在乎數據一致性，且追求極致的并發（但性能提升微乎其微，風險極大）。
實現特點：
- 不使用 MVCC 快照
- 讀操作不加鎖（除非使用 FOR UPDATE 等加鎖讀）
- 性能最高但數據一致性最差
2. 讀已提交 (Read Committed, RC)
在讀已提交級別下，InnoDB 使用 MVCC 確保事務只能讀取已提交的數據。
- 如何解決臟讀： 一個事務只能讀到其他事務已經提交的修改。
- InnoDB 實現：
讀操作 (SELECT)： 每次執行快照讀時都會生成一個新的 ReadView。這意味著每次讀都能看到最新提交的數據。
寫操作 (UPDATE/DELETE)： 使用行級排他鎖，并且語句執行時會掃描最新的數據。它還需要記錄 Undo Log，以便在事務回滾時使用。
- 存在的問題： 因為每次 SELECT 都生成新 ReadView，所以同一事務內兩次讀取可能看到其他事務提交的修改，導致不可重復讀和幻讀。
實現特點：
- 每個語句開始時創建新的 ReadView
- 使用語句級快照而非事務級快照
- 通過 MVCC 避免臟讀
RC 級別下的 MVCC 示例： 假設初始值 balance = 100。
時間序列 | 事務 A (trx_id=10) | 事務 B (trx_id=20) | 事務 A 的 ReadView 與讀取結果 |
T1 |
|
| - |
T2 |
| - | |
T3 |
(生成 ReadView1: m_ids=[10,20], min=10, max=21) 檢查數據行 trx_id=10，它在 m_ids 中且 ≠ 自己，不可見。沿 Undo Log 找到上一個版本(trx_id=可能為 null)，讀取到 100。 | ||
T4 |
| - | |
T5 |
(生成新的ReadView2: m_ids=[20], min=20, max=21) 檢查數據行 trx_id=10，10 < 20 且不在 m_ids 中，可見。讀取到 200。 |
3. 可重復讀 (Repeatable Read, RR)
在可重復讀級別下，InnoDB 使用事務級快照確保事務內讀取一致性。
- 如何解決不可重復讀： 保證一個事務內，多次讀取同一數據的結果是一致的。
- InnoDB 實現：
讀操作 (SELECT)： 只在第一次執行快照讀時生成一個 ReadView，后續所有讀操作都復用這個 ReadView。因此，無論其他事務是否提交，本事務看到的永遠是“快照”那一刻的數據版本。
寫操作 (UPDATE/DELETE) 和 當前讀 (SELECT ... FOR UPDATE/SHARE)： 使用行級鎖和Next-Key Lock（臨鍵鎖） 來防止其他事務修改本事務即將要操作的數據范圍，從而避免幻讀。
- Next-Key Lock： 是行鎖（Record Lock） 和間隙鎖（Gap Lock） 的結合。它鎖住的不僅是一個記錄，還包括該記錄之前的間隙，防止其他事務在這個范圍內插入新數據。
實現特點：
- 在事務第一次讀操作時創建 ReadView
- 整個事務期間使用相同的 ReadView
- 通過 MVCC 避免不可重復讀
- 通過 Next-Key 鎖避免幻讀
RR 級別下的 MVCC 與 Next-Key Lock 示例：
MVCC 部分：
沿用上面的例子，在 T3 時刻事務 B 生成 ReadView 后，在 T5 時刻即使事務 A 提交了，事務 B依然使用舊的 ReadView1進行可見性判斷，因此讀到的依然是 100，實現了可重復讀。
Next-Key Lock 防止幻讀：
- 事務 A：
SELECT * FROM employees WHERE age = 25 FOR UPDATE;(當前讀，加鎖) - 事務 B：
INSERT INTO employees (age) VALUES (25);(被阻塞)
Next-Key 鎖是 InnoDB 在可重復讀隔離級別下避免幻讀的關鍵技術，它是記錄鎖(Record Lock)和間隙鎖(Gap Lock)的組合。
圖片
這條FOR UPDATE語句會在 age=25 的索引記錄上加行鎖，并在其前后間隙加上間隙鎖。事務 B 的插入操作如果 age=25 落在被鎖住的間隙（例如插入一個 25），就會被阻塞，從而避免了幻讀。
圖片
4. 串行化 (Serializable)
- 實現原理： 最嚴格的隔離級別。InnoDB 通過強制所有讀操作都加上共享鎖（
SELECT ... FOR SHARE的隱式版本）來實現。讀寫、寫寫沖突都會嚴重，導致大量事務阻塞，性能最差。 - 應用場景： 對數據一致性要求極高，且可以完全接受并發性能損失的場景，如金融核心賬務系統。
實踐與選擇
理解了原理，我們最終要落地到實踐。如何選擇隔離級別？
1. MySQL 的默認級別：可重復讀 (RR)InnoDB 選擇 RR 作為默認級別，是因為其通過 MVCC 和 Next-Key Lock 在性能和一致性上取得了很好的平衡。在絕大多數應用場景下，它既能保證事務內數據的一致性（避免不可重復讀和幻讀），又提供了比串行化高得多的并發性能。
2. 讀已提交 (RC) 的適用場景近年來，越來越多的應用選擇將隔離級別設置為 RC。原因如下：
- 減少鎖沖突： RR 級別下的 Gap Lock 和 Next-Key Lock 更容易導致死鎖，尤其是在復雜的 SQL 語句下。RC 級別沒有 Gap Lock，寫操作只鎖住必要的行，鎖沖突和死鎖概率大大降低。
- 邏輯清晰： 每次讀都能拿到已提交的最新數據，對于很多邏輯簡單的應用來說更符合直覺。
- 與 Binlog 格式： 在
binlog_format=ROW的情況下，使用 RC 級別的主從復制也是安全的。
選擇 RR 還是 RC？
- 如果你的業務邏輯極度依賴“一個事務內多次讀取數據絕對一致”（例如對賬、報表統計），那么 RR 是更安全的選擇。
- 如果你的業務邏輯以高并發寫入為主，且讀寫沖突不那么嚴重，或者你希望減少死鎖，那么 RC 可能是更好的選擇。許多互聯網高并發應用都使用 RC 級別。
3. 如何設置和查看隔離級別
- 查看當前會話隔離級別：
SELECT @@transaction_isolation; - 設置全局隔離級別 (需重啟)：
SET GLOBAL transaction_isolation = 'READ-COMMITTED'; - 設置當前會話隔離級別：
SET SESSION transaction_isolation = 'REPEATABLE-READ';
4. 避免“長事務”無論選擇哪種隔離級別，長事務都是數據庫的大敵。在 RR 級別下，長事務會導致 Undo Log 版本鏈過長，占用大量存儲空間，影響性能。同時，它持有的鎖可能長時間不釋放，阻塞其他事務。務必監控并優化掉長事務。
總結
MySQL 的事務隔離級別是一個層次分明、權衡精妙的系統。從 RC 到 RR，不僅僅是隔離性的提升，更是 MVCC 從“每次生成視圖”到“第一次生成視圖”的轉變，以及鎖機制從“行鎖”到“Next-Key Lock”的升級。
希望本文通過原理剖析和圖示，能幫助你建立起對 MySQL 事務隔離級別深刻而直觀的理解。
下次當你面對“幻讀”、“不可重復讀”這些問題時，或者當你需要為應用選擇合適的隔離級別時，你的決策將會更加自信和準確。
記住，沒有最好的隔離級別，只有最適合你業務場景的隔離級別。
