本文將不僅詳細解釋每種隔離級別的定義和現(xiàn)象，更會深入 InnoDB 存儲引擎層，探討其背后的多版本并發(fā)控制（MVCC）和鎖機制是如何協(xié)同工作來實現(xiàn)這些隔離級別的。

什么是事務(wù) ACID

在深入隔離級別之前，我們必須先統(tǒng)一共識：什么是事務(wù)？為什么需要它？

事務(wù)是數(shù)據(jù)庫操作的一個最小邏輯工作單元，其內(nèi)的所有操作要么全部成功，要么全部失敗。一個經(jīng)典的例子就是銀行轉(zhuǎn)賬：從 A 賬戶扣款和向 B 賬戶加款，這兩個操作必須作為一個整體，不能分割。

為了確保事務(wù)的可靠性和數(shù)據(jù)的一致性，數(shù)據(jù)庫系統(tǒng)必須滿足 ACID 屬性：

1. 原子性 (Atomicity)： 事務(wù)是一個不可分割的整體，就像原子一樣。它要么全部完成，要么全部不完成，不存在中間狀態(tài)。InnoDB 通過Undo Log來實現(xiàn)原子性。如果事務(wù)失敗，Undo Log 會將已經(jīng)修改的數(shù)據(jù)恢復(fù)到事務(wù)開始前的狀態(tài)。
2. 一致性 (Consistency) ： 事務(wù)的執(zhí)行必須使數(shù)據(jù)庫從一個一致性狀態(tài)變換到另一個一致性狀態(tài)。一致性是應(yīng)用的最終追求，原子性、隔離性和持久性都是為實現(xiàn)一致性而存在的。例如，轉(zhuǎn)賬前后，兩個賬戶的總金額必須保持不變。
3. 隔離性 (Isolation) ： 這是我們今天討論的重點。多個并發(fā)事務(wù)對數(shù)據(jù)進行修改和訪問時，數(shù)據(jù)庫系統(tǒng)必須提供一種機制來防止事務(wù)間的相互干擾，使得各個事務(wù)感覺不到其他事務(wù)在并發(fā)執(zhí)行。隔離級別就是用來定義這種“隔離”的嚴格程度的。
4. 持久性 (Durability) ： 一旦事務(wù)提交，其對數(shù)據(jù)的修改就是永久性的，即使系統(tǒng)發(fā)生故障也不會丟失。InnoDB 通過Redo Log來實現(xiàn)持久性。修改數(shù)據(jù)時，首先會寫入 Redo Log，再在合適的時間點刷寫到磁盤數(shù)據(jù)文件。即使系統(tǒng)崩潰，也能通過 Redo Log 恢復(fù)已提交的事務(wù)。

隔離性的挑戰(zhàn)： 完全隔離（串行化執(zhí)行）固然安全，但會極大限制數(shù)據(jù)庫的并發(fā)處理能力，導(dǎo)致性能急劇下降。因此，數(shù)據(jù)庫系統(tǒng)提供了多種隔離級別，讓開發(fā)者可以在性能和數(shù)據(jù)一致性之間進行權(quán)衡。

并發(fā)事務(wù)并發(fā)的三個問題

在介紹隔離級別之前，我們必須先了解如果不進行任何隔離控制，并發(fā)事務(wù)會引發(fā)哪些問題。隔離級別本質(zhì)上就是為了解決這些問題而存在的。

臟讀 (Dirty Read)

一個事務(wù)讀到了另一個未提交事務(wù)修改的數(shù)據(jù)。如果另一個事務(wù)中途回滾，那么第一個事務(wù)讀到的數(shù)據(jù)就是“臟”的、無效的。

示例：

• 事務(wù) A 將賬戶余額從 100 元修改為 200 元（但未提交）。
• 此時事務(wù) B 讀取余額，得到了 200 元這個結(jié)果。
• 事務(wù) A 因某種原因回滾，余額恢復(fù)為 100 元。
• 事務(wù) B 之后的操作都是基于錯誤的“200 元”余額進行的。

圖片

不可重復(fù)讀 (Non-Repeatable Read)

一個事務(wù)內(nèi)，兩次讀取同一個數(shù)據(jù)項，得到了不同的結(jié)果。重點在于另一個已提交事務(wù)對數(shù)據(jù)進行了修改（UPDATE）。

示例：

• 事務(wù) A 第一次讀取賬戶余額為 100 元。
• 此時事務(wù) B 提交了修改，將余額更新為 150 元。
• 事務(wù) A 再次讀取余額，得到了 150 元。兩次讀取結(jié)果不一致。

幻讀 (Phantom Read)

一個事務(wù)內(nèi)，兩次執(zhí)行同一個查詢，返回的結(jié)果集行數(shù)不同。重點在于另一個已提交事務(wù)對數(shù)據(jù)進行了增刪（INSERT/DELETE），像產(chǎn)生了幻覺一樣。

示例：

• 事務(wù) A 第一次查詢年齡小于 30 歲的員工，返回了 10 條記錄。
• 此時事務(wù) B 提交了一個新操作，插入了一名 25 歲的員工記錄。
• 事務(wù) A 再次執(zhí)行相同的查詢，返回了 11 條記錄。

不可重復(fù)讀 vs 幻讀：

• 不可重復(fù)讀針對的是某一行數(shù)據(jù)的值被修改（UPDATE）。
• 幻讀針對的是結(jié)果集的行數(shù)發(fā)生變化（INSERT/DELETE）。

SQL 標準下的四種事務(wù)隔離級別

為了解決上述問題，SQL 標準定義了四種隔離級別，嚴格程度從低到高。級別越高，能解決的問題越多，但并發(fā)性能通常越低。

注意： 在 MySQL 的 InnoDB 引擎中，通過 Next-Key Locking 技術(shù)，在可重復(fù)讀（Repeatable Read） 隔離級別下就已經(jīng)可以避免絕大部分的幻讀現(xiàn)象。這是 MySQL 對標準隔離級別的增強，也是其默認使用該級別的重要原因。

深入 InnoDB 的 MVCC 與鎖機制

MySQL 的服務(wù)層負責事務(wù)管理，確保在執(zhí)行一系列操作時，滿足原子性、一致性、隔離性和持久性這四個特性。事務(wù)管理涉及的主要功能包括：

1. 事務(wù)隔離級別：MySQL 支持四個事務(wù)隔離級別：讀未提交、讀已提交、可重復(fù)讀和串行化。這些隔離級別分別定義了事務(wù)間數(shù)據(jù)訪問的隔離程度，用于防止臟讀、不可重復(fù)讀和幻讀。
2. 鎖管理：在事務(wù)過程中，可能需要對數(shù)據(jù)加鎖，以確保數(shù)據(jù)的一致性。MySQL 支持的鎖類型包括共享鎖、排它鎖、意向鎖、行鎖、表鎖等。
3. Undo 日志：服務(wù)層通過 Undo 日志實現(xiàn)了事務(wù)回滾操作，當事務(wù)執(zhí)行中途出現(xiàn)異常或用戶發(fā)出回滾請求時，可以通過 Undo 日志回滾數(shù)據(jù)到事務(wù)開始前的狀態(tài)。
4. Redo 日志：為了保證事務(wù)的持久性。

要理解不同隔離級別是如何實現(xiàn)的，我們必須揭開 InnoDB 的兩大核心法寶：多版本并發(fā)控制 (MVCC) 和 鎖 (Locking) 。

MVCC： snapshot vs current

MVCC 的核心思想是為每一行數(shù)據(jù)維護多個版本（通常是兩個），通過某個時間點的“快照”（Snapshot）來讀取數(shù)據(jù)，從而避免加鎖帶來的性能損耗，實現(xiàn)非阻塞的讀操作。

InnoDB 為每行記錄隱式地添加了三個字段：

• DB_TRX_ID（6 字節(jié)）： 最近一次修改該行數(shù)據(jù)的事務(wù) ID。
• DB_ROLL_PTR（7 字節(jié)）： 回滾指針，指向該行數(shù)據(jù)在 Undo Log 中的上一個歷史版本。
• DB_ROW_ID（6 字節(jié)）： 行標識（隱藏的主鍵，如果表沒有主鍵）。

關(guān)鍵概念：ReadView在 MVCC 中，事務(wù)在執(zhí)行快照讀（普通的SELECT語句）時會生成一個一致性視圖，即ReadView。ReadView 是 InnoDB 實現(xiàn) MVCC 的核心數(shù)據(jù)結(jié)構(gòu)，它包含：

• m_ids：生成 ReadView 時活躍的事務(wù) ID 列表
• min_trx_id：活躍事務(wù)中的最小 ID
• max_trx_id：下一個將被分配的事務(wù) ID
• creator_trx_id：創(chuàng)建該 ReadView 的事務(wù) ID

通過 ReadView，InnoDB 可以判斷某個數(shù)據(jù)版本對當前事務(wù)是否可見。

數(shù)據(jù)可見性規(guī)則： 當一行數(shù)據(jù)被訪問時，InnoDB 會遍歷其版本鏈（通過DB_ROLL_PTR指針），并應(yīng)用以下規(guī)則來判斷哪個版本對當前事務(wù)是可見的：

1. 如果數(shù)據(jù)版本的trx_id < min_trx_id，說明該版本在 ReadView 創(chuàng)建前已提交，可見。
2. 如果數(shù)據(jù)版本的trx_id >= max_trx_id，說明該版本在 ReadView 創(chuàng)建后才開啟，不可見。
3. 如果min_trx_id <= trx_id < max_trx_id，則需判斷trx_id是否在m_ids中：

如果在，說明創(chuàng)建 ReadView 時該事務(wù)仍活躍，其修改未提交，不可見。

如果不在，說明創(chuàng)建 ReadView 時該事務(wù)已提交，可見。

4. 如果當前記錄的事務(wù) ID 等于creator_trx_id，說明是本事務(wù)自己修改的，可見。

鎖機制

MVCC 主要解決了“讀”的并發(fā)問題，而“寫”（INSERT, UPDATE, DELETE）依然需要通過加鎖來保證數(shù)據(jù)正確性。

• 共享鎖 (S Lock)： 允許事務(wù)讀一行數(shù)據(jù)。其他事務(wù)可以同時獲取共享鎖，但不能獲取排他鎖。
• 排他鎖 (X Lock)： 允許事務(wù)更新或刪除一行數(shù)據(jù)。其他事務(wù)無法獲取該行的任何鎖。

此外，InnoDB 還引入了意向鎖（Intention Locks），是一種表級鎖，用來表示事務(wù)稍后會對表中的某一行加上哪種類型的鎖（共享或排他）。目的是為了更高效地判斷表級鎖沖突。

圖片

各級別詳解與 InnoDB 實現(xiàn)剖析

現(xiàn)在我們結(jié)合 MVCC 和鎖，來看看每個隔離級別在 InnoDB 中是如何具體工作的。

1. 讀未提交 (Read Uncommitted)

在讀未提交級別下，InnoDB 幾乎不進行隔離控制，事務(wù)可以直接讀取數(shù)據(jù)頁上的最新值，無論其他事務(wù)是否已提交。

• 實現(xiàn)原理： 幾乎不加讀鎖。一個事務(wù)可以直接看到其他未提交事務(wù)修改后的最新值。它直接讀取數(shù)據(jù)頁的最新版本，完全無視 MVCC 和 Undo Log 版本鏈。
• 問題： 所有并發(fā)問題都無法避免。
• 應(yīng)用場景： 幾乎沒有使用場景，除非你完全不在乎數(shù)據(jù)一致性，且追求極致的并發(fā)（但性能提升微乎其微，風(fēng)險極大）。

實現(xiàn)特點：

• 不使用 MVCC 快照
• 讀操作不加鎖（除非使用 FOR UPDATE 等加鎖讀）
• 性能最高但數(shù)據(jù)一致性最差

2. 讀已提交 (Read Committed, RC)

在讀已提交級別下，InnoDB 使用 MVCC 確保事務(wù)只能讀取已提交的數(shù)據(jù)。

• 如何解決臟讀： 一個事務(wù)只能讀到其他事務(wù)已經(jīng)提交的修改。
• InnoDB 實現(xiàn)：

讀操作 (SELECT)： 每次執(zhí)行快照讀時都會生成一個新的 ReadView。這意味著每次讀都能看到最新提交的數(shù)據(jù)。

寫操作 (UPDATE/DELETE)： 使用行級排他鎖，并且語句執(zhí)行時會掃描最新的數(shù)據(jù)。它還需要記錄 Undo Log，以便在事務(wù)回滾時使用。

• 存在的問題： 因為每次 SELECT 都生成新 ReadView，所以同一事務(wù)內(nèi)兩次讀取可能看到其他事務(wù)提交的修改，導(dǎo)致不可重復(fù)讀和幻讀。

實現(xiàn)特點：

• 每個語句開始時創(chuàng)建新的 ReadView
• 使用語句級快照而非事務(wù)級快照
• 通過 MVCC 避免臟讀

RC 級別下的 MVCC 示例： 假設(shè)初始值 balance = 100。

3. 可重復(fù)讀 (Repeatable Read, RR)

在可重復(fù)讀級別下，InnoDB 使用事務(wù)級快照確保事務(wù)內(nèi)讀取一致性。

• 如何解決不可重復(fù)讀： 保證一個事務(wù)內(nèi)，多次讀取同一數(shù)據(jù)的結(jié)果是一致的。
• InnoDB 實現(xiàn)：

讀操作 (SELECT)： 只在第一次執(zhí)行快照讀時生成一個 ReadView，后續(xù)所有讀操作都復(fù)用這個 ReadView。因此，無論其他事務(wù)是否提交，本事務(wù)看到的永遠是“快照”那一刻的數(shù)據(jù)版本。

寫操作 (UPDATE/DELETE) 和 當前讀 (SELECT ... FOR UPDATE/SHARE)： 使用行級鎖和Next-Key Lock（臨鍵鎖） 來防止其他事務(wù)修改本事務(wù)即將要操作的數(shù)據(jù)范圍，從而避免幻讀。

• Next-Key Lock： 是行鎖（Record Lock） 和間隙鎖（Gap Lock） 的結(jié)合。它鎖住的不僅是一個記錄，還包括該記錄之前的間隙，防止其他事務(wù)在這個范圍內(nèi)插入新數(shù)據(jù)。

實現(xiàn)特點：

• 在事務(wù)第一次讀操作時創(chuàng)建 ReadView
• 整個事務(wù)期間使用相同的 ReadView
• 通過 MVCC 避免不可重復(fù)讀
• 通過 Next-Key 鎖避免幻讀

RR 級別下的 MVCC 與 Next-Key Lock 示例：

MVCC 部分：

沿用上面的例子，在 T3 時刻事務(wù) B 生成 ReadView 后，在 T5 時刻即使事務(wù) A 提交了，事務(wù) B依然使用舊的 ReadView1進行可見性判斷，因此讀到的依然是 100，實現(xiàn)了可重復(fù)讀。

Next-Key Lock 防止幻讀：

• 事務(wù) A：SELECT * FROM employees WHERE age = 25 FOR UPDATE; (當前讀，加鎖)
• 事務(wù) B：INSERT INTO employees (age) VALUES (25); (被阻塞)

Next-Key 鎖是 InnoDB 在可重復(fù)讀隔離級別下避免幻讀的關(guān)鍵技術(shù)，它是記錄鎖(Record Lock)和間隙鎖(Gap Lock)的組合。

圖片

這條FOR UPDATE語句會在 age=25 的索引記錄上加行鎖，并在其前后間隙加上間隙鎖。事務(wù) B 的插入操作如果 age=25 落在被鎖住的間隙（例如插入一個 25），就會被阻塞，從而避免了幻讀。

圖片

4. 串行化 (Serializable)

• 實現(xiàn)原理： 最嚴格的隔離級別。InnoDB 通過強制所有讀操作都加上共享鎖（SELECT ... FOR SHARE的隱式版本）來實現(xiàn)。讀寫、寫寫沖突都會嚴重，導(dǎo)致大量事務(wù)阻塞，性能最差。
• 應(yīng)用場景： 對數(shù)據(jù)一致性要求極高，且可以完全接受并發(fā)性能損失的場景，如金融核心賬務(wù)系統(tǒng)。

實踐與選擇

理解了原理，我們最終要落地到實踐。如何選擇隔離級別？

1. MySQL 的默認級別：可重復(fù)讀 (RR)InnoDB 選擇 RR 作為默認級別，是因為其通過 MVCC 和 Next-Key Lock 在性能和一致性上取得了很好的平衡。在絕大多數(shù)應(yīng)用場景下，它既能保證事務(wù)內(nèi)數(shù)據(jù)的一致性（避免不可重復(fù)讀和幻讀），又提供了比串行化高得多的并發(fā)性能。

2. 讀已提交 (RC) 的適用場景近年來，越來越多的應(yīng)用選擇將隔離級別設(shè)置為 RC。原因如下：

• 減少鎖沖突： RR 級別下的 Gap Lock 和 Next-Key Lock 更容易導(dǎo)致死鎖，尤其是在復(fù)雜的 SQL 語句下。RC 級別沒有 Gap Lock，寫操作只鎖住必要的行，鎖沖突和死鎖概率大大降低。
• 邏輯清晰： 每次讀都能拿到已提交的最新數(shù)據(jù)，對于很多邏輯簡單的應(yīng)用來說更符合直覺。
• 與 Binlog 格式： 在binlog_format=ROW的情況下，使用 RC 級別的主從復(fù)制也是安全的。

選擇 RR 還是 RC？

• 如果你的業(yè)務(wù)邏輯極度依賴“一個事務(wù)內(nèi)多次讀取數(shù)據(jù)絕對一致”（例如對賬、報表統(tǒng)計），那么 RR 是更安全的選擇。
• 如果你的業(yè)務(wù)邏輯以高并發(fā)寫入為主，且讀寫沖突不那么嚴重，或者你希望減少死鎖，那么 RC 可能是更好的選擇。許多互聯(lián)網(wǎng)高并發(fā)應(yīng)用都使用 RC 級別。

3. 如何設(shè)置和查看隔離級別

• 查看當前會話隔離級別： SELECT @@transaction_isolation;
• 設(shè)置全局隔離級別 (需重啟)： SET GLOBAL transaction_isolation = 'READ-COMMITTED';
• 設(shè)置當前會話隔離級別： SET SESSION transaction_isolation = 'REPEATABLE-READ';

4. 避免“長事務(wù)”無論選擇哪種隔離級別，長事務(wù)都是數(shù)據(jù)庫的大敵。在 RR 級別下，長事務(wù)會導(dǎo)致 Undo Log 版本鏈過長，占用大量存儲空間，影響性能。同時，它持有的鎖可能長時間不釋放，阻塞其他事務(wù)。務(wù)必監(jiān)控并優(yōu)化掉長事務(wù)。

總結(jié)

MySQL 的事務(wù)隔離級別是一個層次分明、權(quán)衡精妙的系統(tǒng)。從 RC 到 RR，不僅僅是隔離性的提升，更是 MVCC 從“每次生成視圖”到“第一次生成視圖”的轉(zhuǎn)變，以及鎖機制從“行鎖”到“Next-Key Lock”的升級。

希望本文通過原理剖析和圖示，能幫助你建立起對 MySQL 事務(wù)隔離級別深刻而直觀的理解。

下次當你面對“幻讀”、“不可重復(fù)讀”這些問題時，或者當你需要為應(yīng)用選擇合適的隔離級別時，你的決策將會更加自信和準確。

記住，沒有最好的隔離級別，只有最適合你業(yè)務(wù)場景的隔離級別。