MySQL RC 與 RR 隔離級別深度對比：鎖機制、復制相容性、一致性視圖與 Semi-Consistent Read 核心差異

核心差異速覽表

深度解析四大核心差異

1. 鎖機制：Gap Lock 與釋放策略

• RR 需 Gap Lock 解決幻讀：SELECT ... FOR UPDATE、UPDATE、DELETE 走索引時加 Next-Key Lock (Record+Gap)，鎖定區間 (prev, curr]，阻塞插入。
• RC 無 Gap Lock：允許幻讀、不可重複讀，鎖僅加在命中記錄上。
• RC 掃描釋放無效鎖：WHERE 過濾後不符合條件的行，行鎖**即時釋放** (InnoDB 內部優化，違反嚴格兩階段鎖協議)。RR 則**全程持有**。
• 效能結論：大範圍掃描更新場景，RC 鎖衝突顯著低於 RR。

2. 復制相容性：Binlog 格式硬性約束

• Statement 格式在 RC 下不安全：非確定性函數 (NOW()、UUID()) + RC 可見性差異 → 主從數據不一致。
• MySQL 5.6+ 強制 RC 僅支援 ROW/MIXED：早期版本允許 Statement 但報警，後期直接報錯。
• 歷史緣由：MySQL 預設 RR 正是早期僅支援 Statement Binlog 所致。現代架構**統一 ROW 格式**，此限制不再是 RR 唯一優勢。

3. 一致性視圖：ReadView 生命週期

• RC：語句級快照。事務中每條 SELECT 執行瞬間創建 ReadView，見該時刻已提交數據。**同一事務兩次 SELECT 可見不同版本** (不可重複讀)。
• RR：事務級快照。事務首條 SELECT 創建 ReadView，後續所有查詢共用。**同一事務多次 SELECT 見相同版本** (可重複讀)。
• 實現細節：ReadView 含 m_ids (活躍事務 ID 列表)、min_trx_id、max_trx_id。可見性判斷：trx_id < min_trx_id 可見；>= max_trx_id 不可見；在列表中 不可見 (未提交)；不在列表中 可見 (已提交)。

4. Semi-Consistent Read：RC 獨有的 UPDATE 優化

觸發條件：RC 隔離級別 + UPDATE 掃描到**已加鎖記錄**。

流程：

1. InnoDB 返回該行**最新提交版本**給 Server 層 (不加鎖、不等待)。
2. Server 層判斷 WHERE 條件是否滿足。
3. 不滿足：直接跳過，**零鎖開銷**。
4. 滿足：重新發起**當前讀**，加鎖並執行更新。

對比 RR：RR 下 UPDATE 直接當前讀，遇鎖**阻塞等待**，不進行條件預判。

收益：批量更新大量不符合條件行時，RC 大幅減少鎖等待、死鎖概率。

ANSI SQL 標準 vs MySQL 實現

MySQL RR **超標準實現**了防幻讀，這是其選為預設的核心原因之一。

選型決策樹

1. 業務**強依賴可重複讀語義** (如對賬、報表快照) → RR。
2. 使用 **ROW 格式 Binlog**、高併發寫入、無嚴格快照需求 → RC (推薦)。
3. 歷史系統綁定 Statement/Mixed Binlog → RR (被迫)。
4. 極少數嚴格串行化需求 → SERIALIZABLE (效能極差，慎用)。

總結

RC 與 RR 的本質差異在於 **「鎖的激進程度」與「快照的生命週期」**。RC 通過釋放無效鎖、半一致性讀優化更新路徑，適應現代高吞吐場景；RR 通過統一事務級快照、Gap Lock 防幻讀，提供更強一致性保證。理解機制，方能根據業務特性在一致性與性能間做最優權衡。