在 MySQL 數據庫事務隔離級別中，RR（可重復讀） 通過 MVCC（多版本并發控制） 和 鎖機制 的組合策略來避免幻讀問題。

---

一、MVCC機制：快照讀與版本控制

1. 快照讀（Snapshot Read）

   • 每個事務啟動時生成一個全局唯一的 事務版本號，所有 SELECT 操作基于該版本號讀取數據的快照（歷史版本），而非最新數據。
   • 快照規則：
     • 僅讀取 創建版本號 ≤ 當前事務版本號 的數據行。
     • 忽略 刪除版本號 ≤ 當前事務版本號 或未標記刪除的數據行。
   • 效果：同一事務內多次讀取同一范圍的數據時，結果一致（即使其他事務插入新數據并提交）。

2. 版本更新規則

   • INSERT：新插入行的創建版本號設為當前事務版本號。
   • DELETE：標記刪除行的刪除版本號為當前事務版本號。
   • UPDATE：拆分為刪除舊行（標記刪除版本號）和插入新行（設置新創建版本號）。

---

二、鎖機制：當前讀與間隙鎖

1. 當前讀（Current Read）

   • 對數據修改操作（UPDATE/INSERT/DELETE/SELECT FOR UPDATE），強制讀取最新數據版本并加鎖。
   • 鎖類型：
     • 記錄鎖（Row Lock）：鎖定單行數據。
     • 間隙鎖（Gap Lock）：鎖定索引記錄間的間隙，阻止其他事務插入新數據。
     • 臨鍵鎖（Next-Key Lock）：記錄鎖 + 間隙鎖的組合，鎖定一個左開右閉的區間（如 (5, 10]）。

2. 間隙鎖的作用

   • 防止范圍插入：例如事務 A 查詢 age BETWEEN 20 AND 30 的數據并加間隙鎖，事務 B 嘗試插入 age=25 的數據會被阻塞，直到事務 A 提交或回滾。
   • 覆蓋索引與非唯一索引：即使查詢條件未命中實際數據行，間隙鎖仍會鎖定符合條件的索引范圍。

---

三、MySQL InnoDB 的特殊實現

1. RR 與 Serializable 的折中

   • 快照讀：通過 MVCC 避免幻讀（如普通 SELECT 操作）。
   • 當前讀：通過間隙鎖強制串行化，阻止其他事務插入新數據。
   • 實際效果：在 MySQL 的 RR 級別下，幾乎不會出現幻讀（與標準 SQL 定義的 RR 存在差異）。

2. 示例場景

   -- 事務 A
   START TRANSACTION;
   SELECT * FROM users WHERE age BETWEEN 20 AND 30; -- 快照讀，無幻讀
   UPDATE users SET name='Alice' WHERE age=25;      -- 當前讀觸發間隙鎖
   -- 事務 B 插入 age=25 的數據；-- 因為間隙鎖存在，阻塞事務 B 的插入
   COMMIT;
   

3. mysql 幻讀問題
   mysql幻讀是通過MVCC和臨鍵鎖、間隙鎖避免的，但在一些特殊場景下，還是會出現幻讀問題：事務中快照讀和當前讀同時存在時就會出現幻讀問題。

   -- 事務A
   BEGIN;
   SELECT * FROM users WHERE age > 20;  -- 快照讀，未加鎖
   -- 事務B插入age=25的數據并提交
   -- 事務A執行當前讀
   SELECT * FROM users WHERE age > 20 FOR UPDATE;  -- 當前讀，返回包含事務B插入的新數據，發生幻讀
   

---

四、與其他數據庫的對比

數據庫	RR 實現方式	是否完全避免幻讀
MySQL InnoDB	MVCC + 間隙鎖	是（近似）
PostgreSQL	MVCC（無間隙鎖）	否
Oracle	多版本讀一致性（無間隙鎖）	否

---

五、應用注意事項

1. 顯式加鎖的必要性

   • 若需完全避免幻讀，應在事務中對查詢范圍顯式加鎖（如 SELECT ... FOR UPDATE）。
   • 僅依賴快照讀可能無法覆蓋高并發場景下的嚴格一致性需求。

2. 性能權衡

   • 間隙鎖的代價：鎖定范圍可能降低并發寫入性能。
   • 索引設計優化：合理設計索引（如唯一索引）可減少間隙鎖的覆蓋范圍。

---

總結

MySQL 的 RR 隔離級別通過 MVCC 快照讀 和 間隙鎖 的組合，在大多數場景下有效避免了幻讀問題。其實現機制兼顧了性能與一致性，但需注意不同數據庫的差異及實際業務中顯式鎖的使用需求。對于嚴格防幻讀的場景，可升級至 Serializable 級別或通過應用層邏輯補充控制。