三分鐘圖解事務隔離級別，看一遍就懂

前文說過，“鎖 " 是數據庫系統區別於文件系統的一個關鍵特性，其對象是事務，用來鎖定的是數據庫中的對象，如表、頁、行等。鎖確實提高了併發性，但是卻不可避免地存在一些潛在的併發一致性問題。

不過好在鎖只會帶來四種問題（丟失更新、髒讀、不可重複讀、幻讀），如果可以防止這四種情況的發生，那將不會產生併發異常。爲此，ISO 和 ANIS SQL 標準制定了四種事務隔離級別標準，用來對應地解決鎖帶來的幾種問題。

鎖帶來的四種併發一致性問題

丟失更新 Last To Modify

丟失更新非常好理解，簡單來說其就是一個事務的更新操作會被另一個事務的更新操作所覆蓋，從而導致數據的不一致。

舉個例子：

1）事務 T1 將行記錄 r 更新爲 v1，但是事務 T1 並未提交

2）與此同時，事務 T2 將行記錄 r 更新爲 v2，事務 T2 未提交

3）事務 T1 提交

4）事務 T2 提交

如下圖所示，顯然，事務 T1 丟失了自己的修改。

但是，事實上，這種情況準確來講並不會發生。

因爲我們說過對於行進行更新操作的時候，需要對行或其他粗粒度級別的對象加鎖，因此當事務 T1 修改行 r 但是沒提交的時候，事務 T2 對行 r 進行更新操作的時候是會被阻塞住的，直到事務 T1 提交釋放鎖。

所以，從數據庫層面來講，數據庫本身是可以幫助我們阻止丟失更新問題的發生的。

不過，在真實的開發環境中，我們還經常會遇到邏輯意義上的丟失更新。舉個例子：

1）事務 T1 查詢一行數據 r，放入本地內存，並顯示給一個用戶 User1

2）事務 T2 也查詢該行數據，並將取得的數據顯示給另一個用戶 User2

3）User1 修改了行記錄 r 爲 v1，更新數據庫並提交

4）User2 修改了行記錄 r 爲 v2，更新數據庫並提交

顯然，最終這行記錄的值是 v2，User1 的更新操作被 User2 覆蓋掉了，丟失了他的修改。

可能還是雲裏霧裏，我來舉個更現實點的例子吧，一個部門共同查看一個在線文檔，員工 A 發現自己的性別信息有誤，於是將其從 “女” 改成了 “男”，就在這時，HR 也發現了員工 A 的部門信息有誤，於是將其從 ”測試 “ 改成了 ” 開發 “，然後，員工 A 和 HR 同時點了提交，但是 HR 的網絡稍微慢一點，再次刷新，員工 A 就會發現，擦，我的性別怎麼還是 ” 女“？

髒讀 Dirty Read

所謂髒讀，就是說一個事務讀到了另外一個事務中的 "髒數據"，髒數據就是指事務未提交的數據

如下圖所示，在事務並沒有提交的前提下，事務 T1 中的兩次 SELECT 操作取得了不同的結果：

注意，如果想要再現髒讀這種情況，需要把隔離級別調整在 Read UnCommitted（讀取未提交）。所以事實上髒讀這種情況基本不會發生，因爲現在大部分數據庫的隔離級別都至少設置成 READ COMMITTED

不可重複讀 Unrepeatableread

不可重複讀是指在一個事務內多次讀取同一數據集合。在這個事務還沒有結束時，另外一個事務也訪問該同一數據集合，並做了一些修改操作。因此，在第一個事務中的兩次讀數據之間，由於第二個事務的修改，那麼第一個事務兩次讀到的數據可能是不一樣的。

舉個例子：事務 T1 讀取一行數據 r，T2 將該行數據修改成了 v1。如果 T1 再次讀取這行數據，此時讀取的結果和第一次讀取的結果是不同的

不可重複讀和髒讀的區別是：髒讀是讀到未提交的數據，而不可重複讀讀到的卻是已經提交的數據，但是其違反了事務一致性的要求。

幻讀 Phantom Read

幻讀本質上是屬於不可重複讀的一種情況，區別在於，不可重複讀主要是針對數據的更新（即事務的兩次讀取結果值不一樣），而幻讀主要是針對數據的增加或減少（即事務的兩次讀取結果返回的數量不一樣）

舉個例子：事務 T1 讀取某個範圍的數據，事務 T2 在這個範圍內插入了一些新的數據，然後 T1 再次讀取這個範圍的數據，此時讀取的結果比第一次讀取的結果返回的記錄數要多

四種事務隔離級別標準

SQL 標準定義了四種越來越嚴格的事務隔離級別，用來解決我們上述所說的四種事務的併發一致性問題。

1）READ UNCOMMITTED 讀取未提交：事務中的修改，即使沒有提交，對其它事務也是可見的。

上面提到過，數據庫本身其實已經具備阻止丟失更新的能力，也就是說，即使是最低的隔離級別也可以阻止丟失更新問題。所以：

2）READ COMMITTED 讀取已提交：一個事務只能讀取已經提交的事務所做的修改。換句話說，一個事務所做的修改在提交之前對其它事務是不可見的。

3）REPEATABLE READ 可重複讀（InnoDB 存儲引擎默認的隔離級別）：保證在同一個事務中多次讀取同一數據的結果是一樣的

4）SERIALIZABL 可串行化：強制事務串行執行（需要使用鎖機制來實現），這樣多個事務互不干擾，不會出現併發一致性問題。

可以看到四種隔離級別能阻止的併發一致性問題越來越多，但並不代表越高的隔離級別就越好，因爲事務隔離級別越高，數據庫付出的性能代價也就相應地越大。

另外，多提一嘴，InnoDB 存儲引擎在 REPEATABLE READ 事務隔離級別下，使用 Next-Key Lock 鎖的算法避免了幻讀的產生。也就是說，InnoDB 存儲引擎在其默認的 REPEATABLE READ 事務隔離級別下就已經能完全保證事務的隔離性要求了，即達到了 SQL 標準的 SERIALIZABLE 隔離級別。

流水不爭先，爭的是滔滔不絕，我是小牛肉，小夥伴們下篇文章再見 👋

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/b6-FBRtA6BvSXwAEVYSDVg

猜你喜歡