看一遍就懂
前文說過,“鎖" 是資料庫系統差別于檔案系統的一個關鍵特性,其對象是事務,用來鎖定的是資料庫中的對象,如表、頁、行等。鎖确實提高了并發性,但是卻不可避免地存在一些潛在的并發一緻性問題。
不過好在鎖隻會帶來四種問題(丢失更新、髒讀、不可重複讀、幻讀),如果可以防止這四種情況的發生,那将不會産生并發異常。為此,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 隔離級别。
🎉 關注公衆号 | 飛天小牛肉,即時擷取更新
- 部落客東南大學碩士在讀,攜程 Java 背景開發暑期實習生,利用課餘時間營運一個公衆号『 飛天小牛肉 』,2020/12/29 日開通,專注分享計算機基礎(資料結構 + 算法 + 計算機網絡 + 資料庫 + 作業系統 + Linux)、Java 技術棧等相關原創技術好文。關注公衆号第一時間擷取文章更新,
背景回複 300 即可免費擷取極客大學出品的 Java 面試 300 題
- 并推薦個人維護的開源教程類項目: CS-Wiki(Gitee 推薦項目,現已累計 1.8k+ star), 緻力打造完善的後端知識體系,在技術的路上少走彎路,歡迎各位小夥伴前來交流學習 ~ 😊
- 如果各位小夥伴春招秋招沒有拿得出手的項目的話,可以參考我寫的一個項目「開源社群系統 Echo」Gitee 官方推薦項目,目前已累計 900+ star,基于 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 并提供詳細的開發文檔和配套教程。公衆号背景回複 Echo 可以擷取配套教程,目前尚在更新中。