您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 綜合教學

數據庫隔離級別深度解析：髒讀、不可重復讀、幻讀的本質與防禦

編輯：MySQL 綜合教學

核心概念辨析

1. 髒讀

定義：事務 A 修改數據未提交，事務 B 讀取了這份未提交數據。若 A 回滾，B 讀到的即為「髒數據」。

關鍵區別：

髒頁：內存緩衝池中已修改未刷盤的頁，屬正常機制，由 Redo Log 保證持久化。
髒數據：未提交事務的修改，違反隔離性。

2. 不可重復讀

定義：事務 A 先後兩次讀取同一行，中間事務 B 修改並提交了該行，導致 A 兩次結果不一致。核心在「修改」。

例：編輯人員兩次讀取文檔，中間作者修改並保存，第二次讀取內容已變。

3. 幻讀

定義：事務 A 按條件範圍查詢，事務 B 在該範圍**插入/刪除**行並提交，A 再次同條件查詢發現行數變化。核心在「新增/刪除」。

例：編輯處理文檔時，生產部門合並新增章節，導致頁碼錯位。

隔離級別對比矩陣

隔離級別	髒讀	不可重復讀	幻讀	鎖策略	並發性能
READ UNCOMMITTED	✅ 可能	✅ 可能	✅ 可能	無鎖/最輕量	最高
READ COMMITTED (RC)	❌ 不可能	✅ 可能	✅ 可能	鎖定讀取行（行鎖）	高
REPEATABLE READ (RR) MySQL 默認	❌ 不可能	❌ 不可能	✅ 可能	鎖定讀取範圍（Next-Key Lock）	中
SERIALIZABLE	❌ 不可能	❌ 不可能	❌ 不可能	表鎖/範圍鎖	最低

MySQL/InnoDB 實現機制

RR 級別如何解決不可重復讀？

一致性非鎖定讀（Consistent Nonlocking Read）：利用 MVCC（多版本並發控制），讀取事務啟動時刻的快照版本（Undo Log 鏈），不加鎖，不阻塞寫入。

RR 級別為何仍可能幻讀？

快照讀（普通 SELECT）不加鎖，無法防止幻讀。
當前讀（SELECT ... LOCK IN SHARE MODE、FOR UPDATE、UPDATE、DELETE、INSERT）加 **Next-Key Lock**（記錄鎖 + 間隙鎖），鎖定範圍內現有記錄及間隙，防止插入新行，從而解決幻讀。

串行化如何實現？

所有 SELECT 隱式轉為 SELECT ... LOCK IN SHARE MODE，全表/範圍加鎖，實質單線程執行，並發度極低，**生產極少使用**。

實戰選型指南

業務場景	推薦隔離級別	理由
高並發讀多寫少、允許極小概率幻讀（如報表、統計）	RR (默認)	MVCC 無鎖讀，性能最佳；關鍵業務用當前讀加鎖
嚴格金融轉賬、庫存扣減、不可容忍幻讀	RR + 當前讀	Next-Key Lock 保證範圍無幻讀；或應用層樂觀鎖
極簡業務、數據量小、追求絕對一致性	SERIALIZABLE	犧牲並發換取簡單，僅適用極低併發場景
舊系統遷移、依賴 RC 行為（如 Oracle/SQL Server 默認）	RC	需評估幻讀風險，配合應用層重試/冪等

常見誤區澄清

「RR 完全防止幻讀」：錯。僅當前讀防止，快照讀不防止。
「RC 性能一定優於 RR」：不一定。RR 的 MVCC 避免了大量鎖等待，高衝突場景下 RR 往往更優。
「加鎖就能解決所有併發問題」：鎖會帶來死鎖、鎖等待、吞吐下降，應優先考慮無鎖設計（MVCC、樂觀鎖、冪等）。

驗證腳本（可直接運行觀察）

-- Session A
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT * FROM t WHERE id > 10;  -- 快照讀
-- Session B 插入 id=15
SELECT * FROM t WHERE id > 10;  -- 再次快照讀，不會看到 id=15（RR 快照隔離）
-- Session A 當前讀
SELECT * FROM t WHERE id > 10 LOCK IN SHARE MODE;  -- 會阻塞，直到 B 提交/回滾

深入理解隔離級別與鎖機制，是設計高併發、強一致系統的基石。建議結合 SHOW ENGINE INNODB STATUS、performance_schema.data_locks 實地觀察鎖行為，內化為直覺。