最近在準備面試，正把平時積累的筆記、項目中遇到的問題與解決方案、對核心原理的理解，以及高頻業務場景的應對策略系統梳理一遍，既能加深記憶，也能讓知識體系更扎實，供大家參考，歡迎討論。

在數據庫并發操作場景中，事務隔離級別是保障數據一致性的核心機制，不同隔離級別對應不同的并發控制策略，而 MVCC（多版本并發控制）則是實現部分隔離級別的關鍵技術。

一、數據庫事務隔離級別概述

事務隔離級別定義了多個并發事務之間的相互影響程度，從低到高分為四個級別，不同級別在數據一致性和系統性能之間呈現不同的平衡關系。

1.1 讀未提交（Read Uncommitted）

? 定義：最低的隔離級別，允許當前事務讀取其他事務尚未提交的數據變更。

? 核心問題：無法避免臟讀、不可重復讀和幻讀。

? 臟讀：讀取到其他事務未提交的“臨時數據”，若后續事務回滾，當前讀取的數據將變為無效。

? 適用場景：對數據一致性要求極低，僅追求極致性能的場景（如臨時統計查詢，無需精確結果），實際業務中極少使用。業務場景基本都不用。

1.2 讀已提交（Read Committed, RC）

? 定義：允許當前事務讀取其他事務已提交的數據變更，是許多數據庫的默認隔離級別之一（如 Oracle）。

? 核心能力：可阻止臟讀，但仍可能出現不可重復讀和幻讀。

? 不可重復讀：同一事務內，對同一字段多次讀取，結果因其他事務提交的更新操作而不同。? 幻讀：同一事務內，執行相同的查詢語句，結果因其他事務提交的插入/刪除操作而新增或減少數據行。

? 實現依賴：基于 MVCC 機制實現，通過讀取數據的“已提交版本”保障數據有效性。

1.3 可重復讀（Repeatable Read, RR）

? 定義：MySQL InnoDB 引擎的默認隔離級別，確保同一事務內，對同一字段的多次讀取結果一致（除非數據由當前事務自身修改）。

? 核心能力：可阻止臟讀和不可重復讀，但仍可能出現幻讀（需通過額外機制解決）。

? 幻讀解決方案：

? 升級隔離級別至串行化：所有事務順序執行，完全避免并發干擾，但會導致性能大幅下降，僅適用于數據一致性要求極高且并發量低的場景。? MVCC 解決快照讀幻讀：針對簡單 SELECT（快照讀），通過讀取數據的歷史版本（非最新版本），確保同一事務內查詢結果一致。MySQL使用的這個來解決幻讀，相對鎖解決幻讀而言，性能較高。? GapLock + Next-KeyLock 解決當前讀幻讀：針對 SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE 等當前讀操作，通過間隙鎖（GapLock）和 next-key 鎖，鎖定查詢范圍，防止其他事務插入/刪除數據，避免幻讀。

1.4 串行化（Serializable）

? 定義：最高的隔離級別，強制所有事務按順序逐個執行，完全禁止并發操作。互聯網項目基本沒用這個的，項目上線有點并發就會非常卡頓了。

? 核心能力：完全符合 ACID 的隔離要求，可阻止臟讀、不可重復讀和幻讀，數據一致性最強。

? 缺點：極大限制并發性能，僅適用于數據安全性優先于性能的極端場景（如金融核心交易的關鍵步驟）。

二、MVCC（多版本并發控制）機制

MVCC 是一種高效的并發控制技術，主要用于實現 “讀已提交（RC）” 和 “可重復讀（RR）” 隔離級別，通過維護數據的多個版本，實現 “讀 - 寫”“寫 - 讀” 并發執行，在保障數據一致性的同時提升系統性能。

2.1 MVCC 的核心原理

MVCC 的核心是為每行數據維護多個歷史版本，事務讀取時根據自身版本號選擇可見的數據版本，避免直接加鎖導致的并發瓶頸。其關鍵機制包括：

1. 事務版本號
   ? 系統會為每個新啟動的事務分配一個唯一的遞增版本號（transaction_id），事務開始時的版本號即為該事務的標識。

   ? 數據行的版本號與事務版本號關聯，確保事務只能讀取符合可見性規則的數據。

2. 隱藏列與版本鏈
   ? InnoDB 引擎的聚簇索引記錄中，默認包含兩個隱藏列，用于構建數據的版本鏈：

    ? trx_id：存儲每次修改該數據行的事務 ID，記錄數據的“修改者”。? roll_pointer：存儲一個指針，指向該數據行的上一個歷史版本（存儲在 Undo 日志中），通過該指針可串聯所有歷史版本，形成“版本鏈”。
   

   ? 注意：插入操作的 Undo 日志無 roll_pointer，因為插入的數據無歷史版本。

3. Undo 日志的作用
   ? Undo 日志用于保存數據的歷史版本，當事務需要讀取歷史數據時，通過 roll_pointer 從 Undo 日志中獲取對應版本。

   ? 事務提交后，Undo 日志不會立即刪除，而是根據垃圾回收機制（Purge）在合適時機清理，確保其他事務仍能訪問所需的歷史版本。

2.2 MVCC 的適用范圍與限制

? 適用隔離級別：僅支持 “讀已提交（RC）” 和 “可重復讀（RR）”，不支持 “讀未提交”（需讀取未提交數據，與 MVCC 的“版本可見性規則”沖突）和 “串行化”（強制順序執行，無需 MVCC）。

? 適用讀操作類型：

? 快照讀：簡單 SELECT 語句（無 FOR UPDATE、LOCK IN SHARE MODE），通過 MVCC 讀取歷史版本，無需加鎖，并發性能高。? 當前讀：DELETE、UPDATE、INSERT 及 SELECT ... FOR UPDATE 等操作，需讀取數據最新版本，并加鎖防止并發修改，不依賴 MVCC 的版本鏈，而是通過鎖機制保障一致性。

2.3 MVCC 與樂觀鎖的關聯

MySQL 的 MVCC 本質是樂觀鎖的一種實現方式：

? 每行數據的版本號（通過 trx_id 和版本鏈間接體現）作為樂觀鎖的“版本標識”。

? 事務更新數據時，會檢查當前數據的版本號是否與預期一致（類似 “WHERE version = V” 的邏輯），若一致則更新并生成新版本，若不一致則重試或失敗，避免并發沖突。

三、RC 與 RR 隔離級別的應用場景對比

RC 和 RR 均基于 MVCC 實現，但因版本可見性規則不同，適用場景存在顯著差異：

四、關鍵總結

? 事務隔離級別從低到高為：“讀未提交 → 讀已提交 → 可重復讀 → 串行化”，一致性越強，性能越弱，需根據業務場景權衡選擇。

? MVCC 是實現 RC 和 RR 的核心技術，通過版本鏈和 Undo 日志實現“無鎖讀”，提升并發性能。

? RR 的幻讀需通過“MVCC（快照讀）”或“GapLock + Next-KeyLock（當前讀）”解決，RC 因每次查詢讀最新版本，幻讀問題更明顯。