前文說過，“鎖" 是資料庫系統區別于檔案系統的一個關鍵特性，其物件是事務，用來鎖定的是資料庫中的物件，如表、頁、行等，鎖確實提高了并發性，但是卻不可避免地存在一些潛在的并發一致性問題，
不過好在鎖只會帶來四種問題（丟失更新、臟讀、不可重復讀、幻讀），如果可以防止這四種情況的發生，那將不會產生并發例外，為此，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 可以獲取配套教程，目前尚在更新中，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/308621.html
標籤：其他
下一篇：MySQL MHA 運行狀態監控