隔離性

**事務隔離**（英語：Transaction Isolation）定義了資料庫系統中一個事務中操作的結果在何時以何種方式對其他並行事務操作可見。隔離是事務 ACID（原子性、一致性、隔離性、永續性）四大屬性之一。

## 並行控制

並行控制描述了資料庫事務隔離以保證資料正確性的機制。為了保證並列事務執行的準確執行，資料庫和儲存引擎在設計的時候著重強調了並行控制這一點。典型的事務相關機制限制資料的存取順序（執行排程）以滿足可序列化和可恢復性。限制資料存取意味著降低了執行的效能，並行控制機制就是要保證在滿足這些限制的前提下提供儘可能高的效能。在不損害正確性的情況下，可序列化的要求經常會為了效能而妥協，但是為了避免資料一致性的破壞，可恢復性不能夠妥協。

兩階段鎖是關聯式資料庫中最常見的提供了可序列化和可恢復性的並行控制機制，為了存取一個資料庫物件，事務首先要獲得這個物件的鎖。對於不同的存取類型（如對物件的讀或寫操作）和鎖的類型，如果另外一個事務正持有這個物件的鎖，獲得鎖的過程會被阻塞或者延遲。

## 讀現象舉例

ANSI/ISO SQL 92 標準描述了三種不同的一個事務讀取另外一個事務可能修改的資料的「讀現象」。

下面的例子中，我們假設有兩個事務，事務 1 執行語句 1。接著，事務 2 執行語句 2 並且提交，最後事務 1 再執行語句 1。

查詢使用如下的資料表。

### 髒讀

當一個事務允許讀取另外一個事務修改但未提交的資料時，就可能發生髒讀（dirty reads）。

髒讀和不可重複讀類似，不同點在於事務 2 不需要提交就能造成語句 1 兩次執行的結果不同。在未提交讀隔離級別唯一禁止的是更新混亂，即早期的更新可能出現在後來更新之前的結果集中。

在我們的例子中，事務 2 修改了一行，但是沒有提交，事務 1 讀了這個沒有提交的資料。現在如果事務 2 回滾了剛才的修改或者做了另外的修改的話，事務 1 中查到的資料就是不正確的了。

在這個例子中，事務 2 回滾後就沒有 id 是 1，age 是 21 的資料行了。

### 不可重複讀

在一次事務中，當一行資料取得兩遍得到不同的結果表示發生了不可重複讀（non-repeatable reads）.

在基於鎖的並行控制中「不可重複讀」現象發生在當執行 SELECT 操作時沒有獲得讀鎖或者 SELECT 操作執行完後馬上釋放了讀鎖； 多版本並行控制中當沒有要求一個提交衝突 (commit conflict) 的事務回滾也會發生「不可重複讀」現象。

在這個例子中，事務 2 提交成功，因此他對 id 為 1 的行的修改就對其他事務可見了。但是事務 1 在此前已經從這行讀到了另外一個「age」的值。在可序列化（SERIALIZABLE）和可重複讀的隔離級別中，資料庫在第二次 SELECT 請求的時必須返回更新之前的值。在提交讀和未提交讀中，返回的是更新之後的值，這個現象就是不可重複讀。

有兩種策略可以避免不可重複讀。一個是要求事務 2 延遲到事務 1 提交或者回滾之後再執行。這種方式實現了 **T1, T2** 的串行化排程。串行化排程可以支援可重複讀。

另一種被用在_多版本並行控制_的策略是允許事務 2 先提交，這樣能得到更好的並行效能。但因為事務 1 在事務 2 之前開始，事務 1 必須在其開始執行時間點的資料庫的快照上面操作。當事務 1 最終提交時候，資料庫會檢查其結果是否等價於 **T1, T2** 串行排程。如果等價，則允許事務 1 提交，如果不等價，事務 1 需要回滾並丟擲個串行化失敗的錯誤。

使用基於鎖的並行控制，在可重複讀的隔離級別中，ID=1 的行會被鎖住，在事務 1 提交或回滾前一直阻塞語句 2 的執行。在提交讀的級別，語句 1 第二次執行，age 已經被修改了。

在_多版本並行控制_機制下，可序列化 (SERIALIZABLE) 級別，兩次 SELECT 語句讀到的資料都是事務 1 開始的快照，因此返回同樣的資料。但是，如果事務 1 試圖 UPDATE 這行資料，事務 1 會被要求回滾並丟擲一個串行化失敗的錯誤。

在提交讀隔離級別，每個語句讀到的是語句執行前的快照，因此讀到更新前後不同的值。在這種級別不會有串行化的錯誤（因為這種級別不要求串行化），事務 1 也不要求重試。

### 幻影讀

在事務執行過程中，當兩個完全相同的查詢語句執行得到不同的結果集。這種現象稱為「幻影讀（phantom read）」

當事務沒有取得_範圍鎖_的情況下執行 _SELECT ... WHERE_ 操作可能會發生「幻影讀」。

「幻影讀」是_不可重複讀_的一種特殊場景：當事務 1 兩次執行 _SELECT ... WHERE_ 檢索一定範圍內資料的操作中間，事務 2 在這個表中建立了 (如 INSERT) 了一行新資料，這條新資料正好滿足事務 1 的「WHERE」子句。

需要指出的是事務 1 執行了兩遍同樣的查詢語句。如果設了最高的隔離級別，兩次會得到同樣的結果集，這也正是資料庫在可序列化（SERIALIZABLE）隔離級別上需要滿足的。但是在較低的隔離級別上，第二次查詢可能會得到不同的結果集。

在可序列化隔離級別，查詢語句 1 在 age 從 10 到 30 的記錄上加鎖，事務 2 隻能阻塞直至事務 1 提交。在可重複讀級別，這個範圍不會被鎖定，允許記錄插入，因此第二次執行語句 1 的結果中會包括新插入的行。

## 隔離級別

在資料庫事務的 ACID 四個屬性中，隔離性是一個限制最寬鬆的。為了取得更高的隔離等級，資料庫系統的通常使用鎖機制或者多版本並行控制機制。 應用軟體也需要額外的邏輯來使其正常工作。

很多資料庫管理系統（DBMS）定義了不同的「事務隔離等級」來控制鎖的程度。在很多資料庫系統中，多數的事務都避免高等級的隔離等級（如可串行化）從而減少鎖的開銷。程式設計師需要小心的分析資料庫存取部分的代碼來保證隔離級別的降低不會造成難以發現的代碼 bug。相反的，更高的隔離級別會增加死結發生的機率，同樣需要編程過程中去避免。

由於更高的隔離級別中不存在被一個更低的隔離級別禁止的操作，DBMS 被允許使用一個比請求的隔離級別更高的隔離級別。

ANSI/ISO SQL 定義的標準隔離級別如下：

### 可串行化

可串行化（SERIALIZABLE）是最高的隔離級別。

在基於鎖機制並行控制的 DBMS 上，可串行化要求在選定物件上的讀鎖和寫鎖直到事務結束後才能釋放。在 SELECT 的查詢中使用一個「WHERE」子句來描述一個範圍時應該獲得一個「範圍鎖」（range-locks）。這種機制可以避免「幻影讀」現象。

當採用不基於鎖的並行控制時不用取得鎖。但當系統探測到幾個並行事務有「寫衝突」的時候，只有其中一個是允許提交的。這種機制的詳細描述見「快照隔離」

### 可重複讀

在可重複讀（REPEATABLE READS）隔離級別中，基於鎖機制並行控制的 DBMS 需要對選定物件的讀鎖（read locks）和寫鎖（write locks）一直保持到事務結束，但不要求「範圍鎖」，因此可能會發生「幻影讀」。

### 提交讀

在提交讀（READ COMMITTED）級別中，基於鎖機制並行控制的 DBMS 需要對選定物件的寫鎖一直保持到事務結束，但是讀鎖在 SELECT 操作完成後馬上釋放（因此「不可重複讀」現象可能會發生，見下面描述）。和前一種隔離級別一樣，也不要求「範圍鎖」。

### 未提交讀

未提交讀（READ UNCOMMITTED）是最低的隔離級別。允許「髒讀」（dirty reads），事務可以看到其他事務「尚未提交」的修改。

 
通過比低一級的隔離級別要求更多的限制，高一級的級別提供更強的隔離性。標準允許事務執行在更強的事務隔離級別上。(如在可重複讀隔離級別上執行提交讀的事務是沒有問題的)

## 預設隔離級別

不同的 DBMS 預設隔離級別也不同。大多資料庫允許使用者設定隔離級別。有些 DBMS 在執行一個 SELECT 語句時使用額外的語法來取得鎖（如 _SELECT ... FOR UPDATE_ 來獲得在存取的資料行上的排他鎖）。

## 隔離級別、讀現象和鎖

### 隔離級別 vs 讀現象

「可能發生」表示這個隔離級別會發生對應的現象，「-」表示不會發生。

值得一提的是，避免以上三種現象雖然可以滿足 ANSI 對可串行化（Serializable）級別的定義，但是其並非真正的可串行化，不能保證執行效果和串行執行完全一致，可能會出現串行化異常，例如寫偏差和唯讀事務偏差。

### 隔離級別 vs 鎖持續時間

在基於鎖的並行控制中，隔離級別決定了鎖的持有時間。**"C"**- 表示鎖會持續到事務提交。**"S"** –表示鎖持續到當前語句執行完畢。如果鎖在語句執行完畢就釋放則另外一個事務就可以在這個事務提交前修改鎖定的資料，從而造成混亂。

## 參考文獻

## 相關條目

* 原子性
* 一致性
* 永續性
* 鎖
* 樂觀並行控制
* 關聯式資料庫
* 快照隔離

## 外部連結

* Oracle® Database Concepts（頁面存檔備份，存於網際網路檔案館）, chapter 13 Data Concurrency and Consistency, Preventable Phenomena and Transaction Isolation Levels（頁面存檔備份，存於網際網路檔案館）
* Oracle® Database SQL Reference（頁面存檔備份，存於網際網路檔案館）, chapter 19 SQL Statements: SAVEPOINT to UPDATE（頁面存檔備份，存於網際網路檔案館）, SET TRANSACTION（頁面存檔備份，存於網際網路檔案館）
* in JDBC: Connection constant fields（頁面存檔備份，存於網際網路檔案館）, Connection.getTransactionIsolation ()（頁面存檔備份，存於網際網路檔案館）, Connection.setTransactionIsolation (int)（頁面存檔備份，存於網際網路檔案館）
* in Spring Framework: @Transactional, Isolation