介紹弱隔離級別

為什么要有弱隔離級別

如果兩個事務操作的是不同的資料， 即不存在資料依賴關系， 則它們可以安全地并行執行，但是當出現某個事務修改資料而另一個事務同時要讀取該資料， 或者兩個事務同時修改相同資料時， 就會出現并發問題，

在應用程式的開發中，我們通常會利用鎖進行并發控制，確保臨界區的資源不會出現多個執行緒同時進行讀寫的情況，這其實就對應了事務的最高隔離級別：可串行化，可串行化隔離意味著資料庫保證事務的最終執行結果與串行 （即一次一個， 沒有任何并發） 執行結果相同，

那么為什么應用程式中可以提供可串行化的隔離級別，而資料庫卻不能呢？其實根本原因就是應用程式對臨界區大多是記憶體操作，而資料庫要保證持久性（Durability），需要把臨界區的資料持久化到磁盤，可是磁盤操作比記憶體操作要慢好幾個數量級，一次隨機訪問記憶體、 固態硬碟 和 機械硬碟，對應的操作時間分別為幾十納秒、幾十微秒和幾十毫秒，這會導致持有鎖的時間變長，對臨界區資源的競爭將會變得例外激烈，資料庫的性能則會大大降低，

所以，資料庫的研究者就對事務定義了隔離級別這個概念，也就是在高性能與正確性之間做一個權衡，相當于明確地告訴使用者，我們提供了正確性差一點但是性能好一點的模式，以及正確性好一點但是性能差一點的模式，使用者可以根據自己的業務場景來選擇一個合適的隔離級別，

弱隔離級別帶來的風險

弱隔離級別就是非串行化隔離級別，

較弱的隔離級別， 它可以防止某些并發問題，但并非全部的并發問題，

使用這些弱隔離級別，事務并發執行時，可能會出現例外情況，帶來一些難以捉摸的隱患，因此，我們需要了解弱隔離級別存在的并發問題以及如何防范存在的并發問題， 然后， 我們就可以使用所掌握的工具和方法來構建正確、 可靠的應用，

各種隔離級別

SQL-92 標準定義了 4 種事務的隔離級別：讀未提交（Read Uncommitted）、讀已提交（Read Committed）、可重復讀（Repeatable Read）和可串行化（Serializable），在后面的發展程序中，又增加了快照隔離級別（Snapshot Isolation），

不同的弱隔離級別解決了不同的并發問題（正確性問題），同時也存在一些并發問題，

下面是各種隔離級別及對應的并發問題：

• ??代表該隔離級別已解決該并發問題；
• ?代表該隔離級別未解決該并發問題，

SQL 標準對隔離級別的定義還是存在一些缺陷，某些定義模棱兩可，不夠精確，且不能做到與實作無關，所以上面的表格只是對常見的隔離級別并發問題的定義，你可以把它當成一個通用的標準參考，

當你使用某一個資料庫時，需要讀一下它的檔案，確定好它的每一種隔離級別具體的并發問題，

• MySQL 的默認隔離級別為：可重復讀，
• Oracle、PostgreSQL 的默認隔離級別為：讀已提交

事務并發執行時，存在的并發問題

如果兩個事務操作的是不同的資料， 即不存在資料依賴關系， 則它們可以安全地并行執行，但是當出現某個事務修改資料而另一個事務同時要讀取該資料， 或者兩個事務同時修改相同資料時， 就會出現并發問題，

并發問題總結：

• 臟寫：一個事務覆寫了其他事務尚未提交的寫入，
• 臟讀：一個事務讀到了其他事務尚未提交的寫入，
• 不可重復讀：一個事務內，多次讀取同一個記錄的結果不一樣，
• 更新丟失：兩個事務同時執行“讀－修改－寫回”操作序列，事務 A 覆寫了 事務 B 的寫入，但又沒有包含 事務 B 修改后的值，最終導致了部分更新資料發生了丟失，
• 幻讀：一個事務內，多次讀取滿足指定條件的資料，讀出來的結果不一樣，
• 寫傾斜：事務首先查詢資料，根據回傳的結果而作出某些決定，然后修改資料庫，當事務提交時，支持決定的前提條件已不再成立，

臟寫

一個事務覆寫了其他事務尚未提交的寫入，

臟讀

一個事務讀到了其他事務尚未提交的寫入，

舉例說明臟讀

事務 B 修改了 x，在事務 B 提交之前，事務 A 讀到了 x 修改后的資料，這時事務 B 回滾了，相當于事務 A 讀到了一個無效的資料（未實際提交到資料庫中的資料），事務 A 的讀就是臟讀，

不可重復讀

一個事務內，多次讀取同一個記錄的結果不一樣，（一個事務能夠讀到另一個事務對同一個記錄的修改）

舉例說明不可重復讀

事務 A 讀取了 x，然后事務 B 修改了 x 并提交，這時事務 A 再次讀取 x，發現兩次讀取同一個記錄的結果不一樣，這就是不可重復讀，

更新丟失

兩個事務同時執行“讀－修改－寫回”操作序列，事務 A 覆寫了 事務 B 的寫入，但又沒有包含 事務 B 的修改，最終導致了部分更新資料發生了丟失，

舉例說明更新丟失

事務 A 先讀取某記錄，然后事務 B 再讀取某記錄，事務 B 修改并寫回，緊接著 事務 A 修改并寫入，事務 A 覆寫了 事務 B 的寫入，但又沒有包含 事務 B 的修改，最終導致事務 B 的更新丟失了，

幻讀

一個事務內，多次讀取滿足指定條件的資料，讀出來的結果不一樣（一個事務能夠讀到另一個事務創建的滿足條件的記錄）

舉例說明幻讀

事務 A 讀取一組滿足條件 1 的資料，之后事務 B 創建了滿足條件 1 的資料，使其滿足條件 1 并提交，如果事務 A 用相同的 條件 1 再次讀取，得到一組不同于第一次讀取的資料，這就叫幻讀，

不可重復讀和幻讀都是一個事務內，多次執行相同的查詢，結果不一樣，那兩者有什么區別呢？

• 幻讀 主要說的是，讀到了另一個事務的 insert 或者 update 的滿足條件的記錄
• 不可重復讀 主要說的是，讀到了另一個事務對同一個記錄的 update

寫傾斜

寫傾斜就是：事務首先查詢資料，根據回傳的結果而作出某些決定，然后修改資料庫，當事務提交時，支持決定的前提條件已不再成立，

如何防止并發問題

現在我們已經知道了每一個隔離級別可能會出現的并發問題，如果當前資料庫使用了某一個隔離級別，我們也知道這個隔離級別存在的并發問題，是否有辦法來避免并發問題呢？以及對于避免并發問題是如何實作的？

有些并發問題只能通過提升隔離級別來避免，接下來，我們就針對每一種并發問題一一討論，

防止臟寫

允許臟寫這種并發問題出現的資料庫基本上是不可用的，因此所有的隔離級別都不允許出現臟寫這種并發問題，

防止“臟寫”就意味著，寫資料庫時， 只會覆寫已成功提交的資料，

防止臟寫通常的方式是推遲第二個寫請求，直到前面的事務完成提交（或者中止），

資料庫通常采用行級鎖來防止臟寫：如果兩個事務同時嘗試寫入同一個物件時 ，以加鎖的方式來確保第二個寫入等待前面事務完成（包括中止或提交），

這種鎖定是由處于讀已提交模式 （ 或更強的隔離級別） 的資料庫自動完成的，

防止臟讀

防止 “臟讀”就意味著，讀資料庫時， 只能看到已成功提交的資料，

如果業務中不能接受臟讀，那么隔離級別要在“讀已提交”隔離級別或者以上，

當有以下需求時，需要防止臟讀：

• 如果事務需要進行多個操作更新多個物件，我們需要保證另一個事務或者應用層要么看到所有操作執行前的狀態，要么看到所有操作完成后的狀態，而不能看到部分操作完成的中間狀態，如果我們要提供這樣的保證，那么就必須防止臟讀，臟讀意味著另一個事務可能會看到部分更新， 而非全部，觀察到部分更新的資料可能會造成用戶的困惑，
• 如果事務發生中止，則所有寫入操作都需要回滾，那么就必須防止臟讀，避免用戶觀察到一些稍后被回滾的資料， 而這些資料實際并未實際提交到資料庫中，

防止臟讀的解決方案：

• 兩段鎖協議；
• 存盤資料的舊版本和新版本，

一種選擇是使用和防止臟寫相同的鎖，所有試圖讀取該物件的事務必須先申請鎖，事務完成后釋放鎖，從而確保不會發生讀取到一個臟的、 未提交的值，

然而， 加鎖的方式在實際中并不可行， 因為運行時間較長的寫事務會導致許多只讀的事務等待太長時間， 這會嚴重影響只讀事務的回應時間，應用程式任何區域的性能問題會擴散，進而影響整個應用，產生連鎖反應，

因此， 大多數資料庫采用了下面的方式來防止臟讀：對于每個待更新的物件， 資料庫都會維護物件的兩個版本（其舊值 和 當前持鎖事務將要設定的新值），在事務提交之前， 其他事務的讀操作都讀取舊值；僅當寫事務提交之后， 才會切換到讀取新值，而 MySQL 使用了多版本并發控制來防止臟讀，多版本比兩個版本更加通用，

防止不可重復讀

防止“不可重復讀”就意味著，一個事務執行程序中看到的資料，總是跟這個事務在啟動時看到的資料是一致的，

不能忍受不可重復讀的場景：

• 備份場景：備份任務要復制整個資料庫，這可能需要花費幾小時才能完成，在備份程序中，資料可以繼續寫入資料庫，因此，備份里可能包含部分舊版本資料和部分新版本資料， 如果從這樣的備份進行恢復，那么就導致了永久性的不一致，

如果業務中不能接受不可重復讀，那么隔離級別要在“可重復讀”隔離級別或者以上，

在 MySQL 種，可重復讀隔離級別即快照級別隔離，快照級別隔離的總體想法是：每個事務總是在某個時間點的一致性快照中讀取資料，

為了實作快照級別隔離， MySQL 資料庫采用了一種被稱為多版本并發控制（MultiVersion Concurrency Control，MVCC）的機制，

防止更新丟失

更新丟失可能發生在這樣一個操作場景中：應用程式從資料庫讀取某些值，根據應用邏輯做出修改，然后寫回新值 （read-midify-write 程序），當有兩個事務在同樣的資料物件上執行類似操作時，后一個寫操作并不包含前一個寫操作的修改，最終導致前一個寫操作的修改丟失，

更新丟失屬于寫事務并發沖突，

防止更新丟失，目前有多種可行的解決方案，

• 原子更新操作：許多資料庫提供了原子更新操作，以避免在應用層代碼完成“讀－修改－寫回”操作序列，如果資料庫支持原子更新操作的話，通常這就是防止更新丟失最好的解決方案，

• • 原子操作通常采用對讀取物件加獨占鎖的方式來實作，這樣在更新被提交之前其他事務不可以讀取它，
  • 原子操作的另一種實作方式是：強制所有的原子操作都在單執行緒上執行，這也是 Redis 防止更新丟失的解決方案

• 顯式的加鎖：既然原子操作采用對讀取物件加獨占鎖的方式來實作，那么我們也可以顯式的鎖定待更新的物件，使“讀－修改－寫回”操作序列串行執行，例如使用 MySQL 的 select ...... for update;

原子更新操作和 顯式的加鎖 都是通過強制“讀－修改－寫回”操作序列串行執行來防止丟失更新，

• 自動檢測更新丟失：先讓“讀－修改－寫回”操作序列并發執行，但如果事務管理器檢測到了更新丟失風險，則會中止當前事務，并強制回退到安全的“讀－修改－寫回”方式，
• 比較并設定：先讓“讀－修改－寫回”操作序列并發執行，如果讀取的內容已經發生了變化且值與“舊內容”不匹配，則更新失敗，需要應用層再次檢查并在必要時進行重試，例如 update t1 set col1 = '新內容' where id = 1 and col1 = '舊內容';

自動檢測更新丟失

PostgreSQL 的可重復讀， Oracle 的可串行化以及 SQL Server 的快照級別隔離等，都可以自動檢測何時發生了更新丟失，然后會中止違規的那個事務，

但是， MySQL 中 InnoDB 存盤引擎的可重復讀卻并不支持自動檢測更新丟失，

防止幻讀 & 寫傾斜

防止幻讀：

• 使用 可串行化隔離級別
• 在 MySQL 的 可重復讀隔離級別下，使用 select ...... for update;

使用可串行化隔離級別可以防止幻讀，

可串行化隔離通常被認為是最強的隔離級別，使用可串行化隔離級別可以防止所有可能的競爭條件，

可串行化隔離保證即使事務可能會并行執行，但最終的執行結果與每次執行一個事務（即串行執行）的結果相同，

可串行化隔離級別的實作有以下幾種方式：

• 實際串行執行：
• 兩段鎖 + 索引區間鎖：將兩段鎖與索引區間鎖結合使用，實作可串行化隔離
• 可串行化快照隔離：（這個暫時還沒有了解）

MySQL 的可串行化隔離級別使用了第 2 種方法（兩段鎖 + 索引區間鎖）

寫傾斜就是：事務首先查詢資料，根據回傳的結果而作出某些決定，然后修改資料庫，當事務提交時，支持決定的前提條件已不再成立，寫傾斜可能發生在這樣一個操作場景中：

1. 第一步 select：應用程式從資料庫讀取一組滿足條件 1 的資料
2. 第二步 決定：根據查詢的結果，應用層代碼來決定下一步的操作（有可能繼續，或者報告錯誤井中止）
3. 第三步 寫入：如果應用程式決定繼續執行，它將發起資料庫寫入（insert，update 或 delete）并提交事務，

而第 3 步的這個寫操作會改變第 2 步做出決定的前提條件，如果兩個事務并發執行這樣的“讀取-決定-寫入”操作序列，那么后一個寫入改變了前一個寫入執行的前提條件，導致出現意料之外的結果，

防止寫傾斜

對于寫傾斜問題，有幾種可能的解決方案：

• 只使用 可串行化隔離級別 即可避免寫傾斜（使用索引區間鎖，避免其他事務寫入滿足條件的行）
• 更改“讀取-決定-寫入”操作序列的執行順序 為 “寫入-讀取-決定”：先寫入，然后 select 查詢并加獨占鎖（select ...... for update），最后根據查詢的結果來決定是否提交或者放棄，
• 物體化沖突，也稱物化沖突：有的業務場景 select 查詢的是不滿足給定搜索條件的行（例如 select * from t1 where id != 1）如果第 1 步的查詢根本沒有回傳任何行，則 select ...... for update 也就無從加鎖，只能考慮物體化沖突，

本質上這三種可能的解決方案都是對事務所依賴的行顯式的加鎖，

對于物體化沖突（物化沖突）的說明

如果問題的關鍵是查詢結果中沒有物件（空）可以加鎖，或許可以人為引人一些可加鎖的物件，這種方法稱為物體化沖突（或物化沖突），它把幻讀問題轉變為針對資料庫中一組具體行的鎖沖突問題，

然而，弄清楚如何實作物體化往往也具有挑戰性，實作程序也容易出錯，這種把一個并發控制機制降級為資料模型的思路總是不夠優雅，出于這些原因，除非萬不得己，沒有其他可選方案，不推薦采用物體化沖突，

參考資料

24｜事務（三）：隔離性，正確與性能之間權衡的藝術-極客時間 (geekbang.org)

《資料密集型應用系統設計》

本文來自博客園，作者：真正的飛魚，轉載請注明原文鏈接：https://www.cnblogs.com/feiyu2/p/16683430.html

標籤：MySQL

上一篇：Mysql第8天

下一篇：MySQL用戶和權限管理