臟讀、幻讀和不可重復讀是數據庫事務隔離級別中常見的三種數據一致性問題。它們描述了在并發事務環境下可能出現的異常現象。下面通過對比表格和具體示例進行清晰解析：

---

核心概念對比表

問題類型	觸發場景	本質原因	示例
臟讀 (Dirty Read)	事務A讀取了事務B未提交的修改	讀取到其他事務的中間狀態（可能被回滾的數據）	事務B修改數據未提交 → 事務A讀取 → 事務B回滾 → 事務A讀到"臟數據"
不可重復讀 (Non-Repeatable Read)	同一事務內多次讀取同一數據，結果不一致	其他事務修改或刪除了該數據	事務A第一次讀取 → 事務B修改數據并提交 → 事務A再次讀取 → 兩次結果不同
幻讀 (Phantom Read)	同一事務內多次范圍查詢，結果集數量變化	其他事務新增或刪除了范圍內的數據	事務A查詢年齡>30有5人 → 事務B新增1個>30記錄 → 事務A再查變6人

---

詳細解析與示例

一、臟讀（Dirty Read）

• 定義：事務A讀取了事務B尚未提交的修改，若事務B最終回滾，則事務A讀取的是無效的"臟數據"。
• 示例：

  -- 事務B（未提交）
  UPDATE accounts SET balance = 1000 WHERE id = 1;  -- 原值500-- 事務A（讀取未提交數據）
  SELECT balance FROM accounts WHERE id = 1; -- 讀到1000（臟數據！）-- 事務B回滾
  ROLLBACK;  -- balance恢復為500
  

  📌 風險：事務A基于錯誤數據（1000）進行了錯誤操作。

二、不可重復讀（Non-Repeatable Read）

• 定義：同一事務內多次讀取同一數據，由于其他事務的修改或刪除操作，導致讀取結果不一致。
• 示例：

  -- 事務A
  SELECT balance FROM accounts WHERE id = 1; -- 第一次讀：500-- 事務B提交修改
  UPDATE accounts SET balance = 800 WHERE id = 1;
  COMMIT;-- 事務A再次讀取
  SELECT balance FROM accounts WHERE id = 1; -- 第二次讀：800（結果改變！）
  

  📌 影響：事務A無法保證多次讀取的一致性（如校驗數據時結果突變）。

三、幻讀（Phantom Read）

• 定義：同一事務內多次執行范圍查詢，由于其他事務新增或刪除數據，導致結果集數量變化（如"憑空出現"新記錄）。
• 示例：

  -- 事務A：查詢年齡>30的員工
  SELECT * FROM employees WHERE age > 30; -- 返回5條記錄-- 事務B新增并提交
  INSERT INTO employees (name, age) VALUES ('Bob', 35);
  COMMIT;-- 事務A再次查詢
  SELECT * FROM employees WHERE age > 30; -- 返回6條記錄（多出Bob！）
  

  📌 關鍵區別：幻讀關注結果集數量變化（增刪導致），不可重復讀關注單條數據的值變化。

---

隔離級別如何解決這些問題？

數據庫通過四種隔離級別控制并發問題：

隔離級別	臟讀	不可重復讀	幻讀	性能
READ UNCOMMITTED (讀未提交)	?	?	?	最高
READ COMMITTED (讀已提交)	?	?	?	高
REPEATABLE READ (可重復讀)	?	?	?*	中等
SERIALIZABLE (串行化)	?	?	?	最低

💡 說明：

• ? = 可避免該問題
• ? = 無法避免
• ?* = MySQL的InnoDB引擎通過 MVCC（多版本并發控制） 解決了幻讀，但部分數據庫（如SQL Server）仍需串行化才能避免。

---

技術原理剖析

1. 讀已提交（READ COMMITTED）

   • 通過 語句級快照：每次查詢只讀取已提交的數據。
   • 解決臟讀，但無法避免不可重復讀和幻讀。

2. 可重復讀（REPEATABLE READ）

   • 通過 事務級快照（MVCC）：事務首次查詢建立數據快照，后續讀取均基于此版本。
   • 解決臟讀和不可重復讀。
   • MySQL如何解決幻讀：
     • 使用 Next-Key Locking（間隙鎖+記錄鎖）鎖定查詢范圍，阻止其他事務插入（能解決大部分的幻讀問題，但是并不能完全解決幻讀）。

3. 串行化（SERIALIZABLE）

   • 通過 完全加鎖：所有操作串行執行，犧牲并發性換取一致性。
   • 解決臟讀、不可重復讀和幻讀。

---

實際開發建議

• 優先選擇 READ COMMITTED：平衡性能與一致性（多數場景適用）。
• 關鍵業務用 REPEATABLE READ：如賬戶余額計算。
• 極少用 SERIALIZABLE：除非絕對要求數據完美一致（如銀行清算系統）。

?? 注意：不同數據庫實現有差異（如Oracle默認READ COMMITTED，MySQL默認REPEATABLE READ）。