• 隔離性的4個級別
  • 概覽
    • 讀未提交
    • 讀已提交
    • 可重複讀
    • 可序列化
  • 原理
    • 讀未提交
    • 讀已提交
    • 可重複讀
      • 悲觀策略：序列化
      • 樂觀策略：多版本 + 衝突檢測
      • 幻讀問題
    • 可序列化
  • 隔離性級別的總結

隔離性的4個級別

在理解隔離性級別時，很容易混淆“幻讀”與“不可重複讀”的問題。這裡先對4個隔離性級別給出概覽；然後分析原理，從實現角度理解各種問題；最後作出總結。

概覽

關注隔離性的4個級別，包括讀未提交（Read Uncommitted）、讀已提交（Read Committed）、可重複讀（Repeatable Read）、可序列化（Serializable）；及其對應的問題，包括髒讀、不可重複讀、幻讀。

讀未提交

讀未提交是資料庫應保證的最低的隔離性級別：事務中的修改，即使沒有提交，對其他事務也都是可見的

讀未提交面臨髒讀的問題：事務可以讀取未提交的資料，而該資料可能在未來因回滾而消失。從效能上來說，讀未提交不會比其他的級別好太多，但卻缺乏其他級別的很多好處。除非真的有非常必要的理由，在實際應用中很少使用。

讀已提交

讀已提交滿足前面提到的隔離性的簡單定義：一個事務所做的修改在最終提交以前，對其他事務是不可見的。換句話說，一旦提交，該事務所作的修改對其他正在進行中的事務就是可見的。

狹義上，讀已提交解決了髒讀的問題。這個級別有時候叫做不可重複讀，面臨不可重複讀的問題：兩次執行同樣的查詢，如果第二次讀到了其他事務提交的結果，則會得到不一樣的結果。

大多數資料庫的預設隔離級別都是Read Committed，但MySQL不是。

可重複讀

在讀已提交的基礎上，可重複讀解決了部分不可重複的問題：同一個事務中多次讀取同樣記錄結果是一致的。記錄指具體的資料行。

未能解決的那部分稱為幻讀：當某個事務在讀取目標範圍內的記錄時，另一個事務又在該範圍內插入了新的記錄，當之前的事務再次讀取該範圍的記錄時，會產生第一次讀取範圍時不存在的幻行（Phantom Row）。需要注意的是，只有插入會產生幻行。

MySQL的預設隔離級別是可重複讀，有幻讀問題。

可序列化

可序列化是最高的隔離級別：強制事務序列化執行。

可序列化解決了幻讀問題。簡單來說，可序列化會在目標範圍加獨佔鎖，將併發讀寫相同範圍資料的請求序列化。可序列化會導致大量的超時和鎖爭用問題，因此，實際應用中很少用到這個隔離級別，只有在非常需要確保資料的一致性而且可以接受沒有併發的情況下，才考慮採用該級別。

原理

討論基於鎖的併發控制中，4種隔離性級別的實現原理。重點關注讀鎖（read lock，或稱共享鎖）、寫鎖（write lock，或稱排它鎖）、範圍鎖（range lock）、鎖的持有時間等概念。

讀鎖又稱為共享鎖，共享鎖就是多個事務共享一把鎖，都能訪問到資料，但都只能讀不能修改。

寫鎖又稱為排他鎖，排他鎖和其他事務不能共存，如果一個事務獲取了一個數據行的排他鎖，其他的事務不可以再獲取到該資料行的任何鎖，獲取到排他鎖的資料行可以對行進行讀取和修改，沒有獲取到鎖的資料行 不能 讀取和修改。

mysql的innoDB引擎預設修改的語句都會加上排他鎖，比如update insert delete

範圍鎖針對目標範圍，一般是指sql語句中where約束的範圍

讀未提交

讀未提交的實現：讀鎖、寫鎖都在一個原子操作（如select、insert等）完成後立即釋放。換句話說，事務作出更新後，不管是否提交，都會釋放目標記錄的寫鎖，更新對其他事務就是可見的。

讀未提交存在髒讀問題，假設操作序列：

1. 事務1開始
2. 事務1讀取目標記錄
3. 事務2開始
4. 事務2修改目標記錄
5. 事務1讀取目標記錄 // 讀取到了操作4的修改
6. 事務2回滾
7. 事務1提交

操作5中，事務1讀到了事務2修改但未提交的記錄，然後事務2回滾導致修改丟失，也就稱事務1讀到了“髒資料”（即不存在的資料），即髒讀。

區分目標記錄與目標範圍（見後文可重複讀的實現原理）：

• 目標記錄指一個具體的資料行；讀鎖、寫鎖只針對目標記錄。
• 目標範圍指一個where語句描述的範圍；範圍鎖針對目標範圍，見後。

讀已提交

出現髒讀的原因是寫鎖的持有時間過短。讀已提交針對這一問題作出了優化：讀鎖仍然在一個原子操作完成後立即釋放；寫鎖從寫操作開始持有，事務提交後釋放。事務作出更新前，會先申請目標記錄的寫鎖，並持續持有至事務提交後，釋放寫鎖後，更新對其他事務才是可見的。

對於 讀未提交 中的操作序列，操作5發生時，由於事務2持有目標記錄的寫鎖，事務1讀取目標記錄會阻塞，直到事務2提交釋放該寫鎖，所以 讀已提交 解決了髒讀問題。

讀已提交還存在不可重複讀問題。假設操作序列：

1. 事務1開始
2. 事務1讀取目標記錄
3. 事務2開始
4. 事務2修改目標記錄
5. 事務2提交
6. 事務1修改目標記錄
7. 事務1提交

操作5完成後，事務2的修改對事務1可見，從而操作6中，事務1會讀到修改，與操作2的結果不同，因此修改結果無法保證正確（如根據操作2讀取的結果做修改）；但是事務1在此之前未對目標記錄作出任何修改，因此事務1進行操作6時的狀態理應與操作2後一致（回顧事務的一致性要求）。以上即為不可重複讀。

不可重複讀與髒讀之間存在交叉。髒讀側重讀到不應存在的資料。不可重複讀強調兩次相同查詢的結果不一樣。實際上，可以將描述放寬到“目標記錄修改時的狀態不符合預期狀態”。

可重複讀

解決不可重複讀可以使用兩種方法：

1. 悲觀策略（悲觀鎖）：序列化
2. 樂觀策略（樂觀鎖）：多版本 + 衝突檢測

悲觀策略：序列化

“序列化”不需要解釋，放棄併發、序列執行，當然不存在任何問題。

“序列化”的可重複讀實現是：讀鎖、寫鎖都從讀、寫操作開始持有，事務提交後釋放。與讀已提交的實現相比，可重複讀延長讀鎖的持有時間直到事務提交後，在此期間，目標記錄無法被修改。

1. 事務1開始
2. 事務1讀取目標記錄
3. 事務2開始
4. 事務2修改目標記錄
5. 事務2提交
6. 事務1修改目標記錄
7. 事務1提交

對於讀已提交中的操作序列，操作2發生時，事務1開始持有目標記錄的讀鎖，導致事務2的操作4會陷入阻塞，直到事務1提交釋放鎖。

“序列化”不同於“可序列化”。為了區分，前、後文中均將隔離性級別稱為“可序列化”，將此處的悲觀策略稱為“序列化”。

樂觀策略：多版本 + 衝突檢測

“多版本 + 衝突檢測”是更常見的實現方案：多個事務採用多個版本，最後提交時檢測是否與當前資料版本衝突，如果衝突則報錯提醒，否則成功提交。

“多版本 + 衝突檢測”的可重複讀實現是：事務開始時持有當前資料的快照，讀寫均不衝突，提交時檢測修改的快照與當前資料是否衝突。使用樂觀的衝突檢測策略代替悲觀的鎖策略，在中低程度的併發情況下效能更好。

對於讀已提交中的操作序列，事務1、2各自持有快照，在操作4修改自己版本的目標記錄後，操作5提交事務2，檢測不衝突（假設沒有其他事務），合併到當前資料，當前資料完成修改；然後操作6繼續修改自己版本的目標記錄，操作7提交事務1，發現自己版本的快照修改後的記錄 與 當前資料應用事務操作後的結果 衝突，給出報錯。

關於快照衝突檢測：各事務對自己的快照修改操作。把自己快照修改後的結果 與 當前資料應用事務操作後的結果對比，相同，則無衝突，反之。

幻讀問題

幻讀是一種特殊的不可重複讀。

為什麼會出現幻讀問題呢？

Java的內建鎖以物件為單位，RDBMS的鎖呢？前面的註釋中略有介紹。為了提高併發效能，簡單的以資料表、資料庫為單位實現鎖的效能過低；標準SQL中，讀、寫鎖以記錄（資料行）為單位。範圍鎖以範圍（邏輯上的範圍，用where描述）為單位。如果沒有範圍鎖，那麼顯然讀、寫鎖只能“鎖”在已存在的記錄上。假設操作序列，這次具體一些：

1. 事務1開始
2. 事務1統計表內資料的總行數
3. 事務2開始
4. 事務2插入一條新紀錄
5. 事務2提交
6. 事務1利用“舊的總行數+新的資料表內容”計算區分度
7. 事務1提交

該操作序列是讀已提交中操作序列的一個具體例項。因此，可以解決部分不可重複讀問題，不能解決的那部分就是幻讀了。

以基於鎖的“序列化”方案為例（“多版本+併發衝突”同理），假設不使用範圍鎖，則幻讀表現如下：由於事務2插入的記錄不獲取鎖，操作2獲取的讀鎖無法發揮作用，操作5提交事務2後，新記錄就對事務1可見了；操作6讀取時，事務1認為一致性依然滿足，便使用了舊的總行數，並重新讀表計算distinct count，卻讀到了一條意料之外的新紀錄，破壞了一致性——好像出現了幻覺一樣，這條新紀錄就被稱為“幻行”，該現象即“幻讀”。

可序列化

對於基於鎖的“序列化”方案，可序列化實現：從各操作開始前持有讀鎖、寫鎖、範圍鎖，直到事務提交後釋放。

對於“多版本 + 衝突檢測”方案，可序列化基於更嚴格的寫衝突檢測來實現，詳見“快照隔離”技術，此處不展開。

範圍鎖如何解決幻讀問題呢？

範圍鎖是一個邏輯概念上的鎖，事務從讀、寫操作（帶顯式或隱式where）開始前持有範圍鎖，直到事務提交後釋放。忽略讀、寫鎖，對可重複讀中操作序列的影響如下：操作2中事務1獲取了目標範圍上的範圍鎖，操作4發現目標範圍被鎖，陷入阻塞，直到操作7事務提交。

隔離性級別的總結

各隔離級別解決了不同的問題。"Y"說明存在問題，"-"說明不存在：

在基於鎖的併發控制中，依靠不同的鎖持有時間實現各隔離級別。鎖均從操作前開始持有，"S"表示操作結束後釋放，"C"表示事務提交後釋放：

MySQL的預設隔離級別是可重複讀，解決了髒讀、部分不可重複讀問題，有幻讀問題。