如果兩個事務操作的是不同的資料， 即不存在資料依賴關係， 則它們可以安全地並行執行。但是當出現某個事務修改資料而另一個事務同時要讀取該資料， 或者兩個事務同時修改相同資料時， 就會出現並行問題。
在應用程式的開發中，我們通常會利用鎖進行並行控制，確保臨界區的資源不會出現多個執行緒同時進行讀寫的情況，這其實就對應了事務的最高隔離級別：可序列化。可序列化隔離意味著資料庫保證事務的最終執行結果與序列 （即一次一個， 沒有任何並行） 執行結果相同。
那麼為什麼應用程式中可以提供可序列化的隔離級別，而資料庫卻不能呢？其實根本原因就是應用程式對臨界區大多是記憶體操作，而資料庫要保證永續性（Durability），需要把臨界區的資料持久化到磁碟，可是磁碟操作比記憶體操作要慢好幾個數量級，一次隨機存取記憶體、 固態硬碟 和 機械硬碟，對應的操作時間分別為幾十納秒、幾十微秒和幾十毫秒，這會導致持有鎖的時間變長，對臨界區資源的競爭將會變得異常激烈，資料庫的效能則會大大降低。
所以，資料庫的研究者就對事務定義了隔離級別這個概念，也就是在高效能與正確性之間做一個權衡，相當於明確地告訴使用者，我們提供了正確性差一點但是效能好一點的模式，以及正確性好一點但是效能差一點的模式，使用者可以根據自己的業務場景來選擇一個合適的隔離級別。
弱隔離級別就是非序列化隔離級別。
較弱的隔離級別， 它可以防止某些並行問題，但並非全部的並行問題。
使用這些弱隔離級別，事務並行執行時，可能會出現異常情況，帶來一些難以捉摸的隱患，因此，我們需要了解弱隔離級別存在的並行問題以及如何防範存在的並行問題。 然後， 我們就可以使用所掌握的工具和方法來構建正確、 可靠的應用。
SQL-92 標準定義了 4 種事務的隔離級別：讀未提交（Read Uncommitted）、讀已提交（Read Committed）、可重複讀（Repeatable Read）和可序列化（Serializable），在後面的發展過程中，又增加了快照隔離級別（Snapshot Isolation）。
不同的弱隔離級別解決了不同的並行問題（正確性問題），同時也存在一些並行問題。
下面是各種隔離級別及對應的並行問題：
| 髒寫 | 髒讀 | 不可重複讀 | 更新丟失 | 幻讀 | 寫傾斜 | |
|---|---|---|---|---|---|---|
| 讀未提交 | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ |
| 讀已提交 | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ |
| 可重複讀 | ✔️ | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| 快照 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| 可序列化 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
SQL 標準對隔離級別的定義還是存在一些缺陷，某些定義模稜兩可，不夠精確，且不能做到與實現無關，所以上面的表格只是對常見的隔離級別並行問題的定義，你可以把它當成一個通用的標準參考。
當你使用某一個資料庫時，需要讀一下它的檔案，確定好它的每一種隔離級別具體的並行問題。
如果兩個事務操作的是不同的資料， 即不存在資料依賴關係， 則它們可以安全地並行執行。但是當出現某個事務修改資料而另一個事務同時要讀取該資料， 或者兩個事務同時修改相同資料時， 就會出現並行問題。
並行問題總結：
一個事務覆蓋了其他事務尚未提交的寫入。
一個事務讀到了其他事務尚未提交的寫入。
舉例說明髒讀
事務 B 修改了 x，在事務 B 提交之前，事務 A 讀到了 x 修改後的資料。這時事務 B 回滾了，相當於事務 A 讀到了一個無效的資料（未實際提交到資料庫中的資料），事務 A 的讀就是髒讀。
| 時間順序 | Session A | Session B |
|---|---|---|
| 1 | begin; | begin; |
| 2 | update t1 set c1 = 'B' where id = 1 | |
| 3 | select * from t1 where id = 1 | |
| 4 | commit; | |
| 5 | rollback; |
一個事務內，多次讀取同一個記錄的結果不一樣。（一個事務能夠讀到另一個事務對同一個記錄的修改）
舉例說明不可重複讀
事務 A 讀取了 x，然後事務 B 修改了 x 並提交。這時事務 A 再次讀取 x，發現兩次讀取同一個記錄的結果不一樣，這就是不可重複讀。
| 時間順序 | Session A | Session B |
|---|---|---|
| 1 | begin; | 該事務設定自動提交 |
| 2 | select * from t1 where id = 1（此時讀到 A） | |
| 3 | update t1 set c1 = 'B' where id = 1 | |
| 4 | select * from t1 where id = 1（此時讀到 B） | |
| update t1 set c1 = 'C' where id = 1 | ||
| 5 | select * from t1 where id = 1（此時讀到 C） |
兩個事務同時執行「讀－修改－寫回」操作序列，事務 A 覆蓋了 事務 B 的寫入，但又沒有包含 事務 B 的修改，最終導致了部分更新資料發生了丟失。
舉例說明更新丟失
事務 A 先讀取某記錄，然後事務 B 再讀取某記錄，事務 B 修改並寫回，緊接著 事務 A 修改並寫入。事務 A 覆蓋了 事務 B 的寫入，但又沒有包含 事務 B 的修改，最終導致事務 B 的更新丟失了。
| 時間順序 | Session A | Session B |
|---|---|---|
| 1 | begin; | begin; |
| 2 | select * from t1 where id = 1; | |
| 3 | select * from t1 where id = 1 | |
| 4 | update t1 set col1 = 2 where id = 1; | |
| 5 | update t1 set col1 = 3 where id = 1; |
一個事務內，多次讀取滿足指定條件的資料，讀出來的結果不一樣（一個事務能夠讀到另一個事務建立的滿足條件的記錄）
舉例說明幻讀
事務 A 讀取一組滿足條件 1 的資料，之後事務 B 建立了滿足條件 1 的資料，使其滿足條件 1 並提交，如果事務 A 用相同的 條件 1 再次讀取，得到一組不同於第一次讀取的資料。這就叫幻讀。
| 時間順序 | Session A | Session B |
|---|---|---|
| 1 | begin; | 該事務設定自動提交 |
| 2 | select * from t1 where id > 0 | |
| 3 | insert into t1 values(B) | |
| 4 | select * from t1 where id > 0（能讀到 B） |
不可重複讀和幻讀都是一個事務內，多次執行相同的查詢，結果不一樣。那兩者有什麼區別呢？
寫傾斜就是：事務首先查詢資料，根據返回的結果而作出某些決定，然後修改資料庫。當事務提交時，支援決定的前提條件已不再成立。
現在我們已經知道了每一個隔離級別可能會出現的並行問題，如果當前資料庫使用了某一個隔離級別，我們也知道這個隔離級別存在的並行問題，是否有辦法來避免並行問題呢？以及對於避免並行問題是如何實現的？
有些並行問題只能通過提升隔離級別來避免，接下來，我們就針對每一種並行問題一一討論。
允許髒寫這種並行問題出現的資料庫基本上是不可用的。因此所有的隔離級別都不允許出現髒寫這種並行問題。
防止「髒寫」就意味著，寫資料庫時， 只會覆蓋已成功提交的資料。
防止髒寫通常的方式是推遲第二個寫請求，直到前面的事務完成提交（或者中止）。
資料庫通常採用行級鎖來防止髒寫：如果兩個事務同時嘗試寫入同一個物件時 ，以加鎖的方式來確保第二個寫入等待前面事務完成（包括中止或提交）。
這種鎖定是由處於讀已提交模式 （ 或更強的隔離級別） 的資料庫自動完成的。
防止 「髒讀」就意味著，讀資料庫時， 只能看到已成功提交的資料。
如果業務中不能接受髒讀，那麼隔離級別要在「讀已提交」隔離級別或者以上。
當有以下需求時，需要防止髒讀：
防止髒讀的解決方案：
一種選擇是使用和防止髒寫相同的鎖，所有試圖讀取該物件的事務必須先申請鎖，事務完成後釋放鎖，從而確保不會發生讀取到一個髒的、 未提交的值。
然而， 加鎖的方式在實際中並不可行， 因為執行時間較長的寫事務會導致許多唯讀的事務等待太長時間， 這會嚴重影響唯讀事務的響應時間。應用程式任何區域性的效能問題會擴散，進而影響整個應用，產生連鎖反應。
因此， 大多數資料庫採用了下面的方式來防止髒讀：對於每個待更新的物件， 資料庫都會維護物件的兩個版本（其舊值 和 當前持鎖事務將要設定的新值）。在事務提交之前， 其他事務的讀操作都讀取舊值；僅當寫事務提交之後， 才會切換到讀取新值。而 MySQL 使用了多版本並行控制來防止髒讀，多版本比兩個版本更加通用。
防止「不可重複讀」就意味著，一個事務執行過程中看到的資料，總是跟這個事務在啟動時看到的資料是一致的。
不能忍受不可重複讀的場景：
如果業務中不能接受不可重複讀，那麼隔離級別要在「可重複讀」隔離級別或者以上。
在 MySQL 種，可重複讀隔離級別即快照級別隔離。快照級別隔離的總體想法是：每個事務總是在某個時間點的一致性快照中讀取資料。
為了實現快照級別隔離， MySQL 資料庫採用了一種被稱為多版本並行控制（MultiVersion Concurrency Control，MVCC）的機制。
更新丟失可能發生在這樣一個操作場景中：應用程式從資料庫讀取某些值，根據應用邏輯做出修改，然後寫回新值 （read-midify-write 過程）。當有兩個事務在同樣的資料物件上執行類似操作時，後一個寫操作並不包含前一個寫操作的修改，最終導致前一個寫操作的修改丟失。
更新丟失屬於寫事務並行衝突。
防止更新丟失，目前有多種可行的解決方案。
原子更新操作：許多資料庫提供了原子更新操作，以避免在應用層程式碼完成「讀－修改－寫回」操作序列，如果資料庫支援原子更新操作的話，通常這就是防止更新丟失最好的解決方案。
顯式的加鎖：既然原子操作採用對讀取物件加獨佔鎖的方式來實現，那麼我們也可以顯式的鎖定待更新的物件，使「讀－修改－寫回」操作序列序列執行。例如使用 MySQL 的 select ...... for update;
原子更新操作和 顯式的加鎖 都是通過強制「讀－修改－寫回」操作序列序列執行來防止丟失更新。
自動檢測更新丟失
PostgreSQL 的可重複讀， Oracle 的可序列化以及 SQL Server 的快照級別隔離等，都可以自動檢測何時發生了更新丟失，然後會中止違規的那個事務。
但是， MySQL 中 InnoDB 儲存引擎的可重複讀卻並不支援自動檢測更新丟失。
防止幻讀：
- 使用 可序列化隔離級別
- 在 MySQL 的 可重複讀隔離級別下，使用 select ...... for update;
使用可序列化隔離級別可以防止幻讀。
可序列化隔離通常被認為是最強的隔離級別。使用可序列化隔離級別可以防止所有可能的競爭條件。
可序列化隔離保證即使事務可能會並行執行，但最終的執行結果與每次執行一個事務（即序列執行）的結果相同。
可序列化隔離級別的實現有以下幾種方式：
MySQL 的可序列化隔離級別使用了第 2 種方法（兩段鎖 + 索引區間鎖）
寫傾斜就是：事務首先查詢資料，根據返回的結果而作出某些決定，然後修改資料庫。當事務提交時，支援決定的前提條件已不再成立。寫傾斜可能發生在這樣一個操作場景中：
而第 3 步的這個寫操作會改變第 2 步做出決定的前提條件，如果兩個事務並行執行這樣的「讀取-決定-寫入」操作序列，那麼後一個寫入改變了前一個寫入執行的前提條件，導致出現意料之外的結果。
防止寫傾斜
對於寫傾斜問題，有幾種可能的解決方案：
本質上這三種可能的解決方案都是對事務所依賴的行顯式的加鎖。
對於實體化衝突（物化衝突）的說明
如果問題的關鍵是查詢結果中沒有物件（空）可以加鎖，或許可以人為引人一些可加鎖的物件。這種方法稱為實體化衝突（或物化衝突），它把幻讀問題轉變為針對資料庫中一組具體行的鎖衝突問題。
然而，弄清楚如何實現實體化往往也具有挑戰性，實現過程也容易出錯，這種把一個並行控制機制降級為資料模型的思路總是不夠優雅。出於這些原因，除非萬不得己，沒有其他可選方案，不推薦採用實體化衝突。
24｜事務（三）：隔離性，正確與效能之間權衡的藝術-極客時間 (geekbang.org)
《資料密集型應用系統設計》
本文來自部落格園，作者：真正的飛魚，轉載請註明原文連結：https://www.cnblogs.com/feiyu2/p/16683430.html