[中級]深刻分析事務的隔離級別

本文詳細介紹四種事務隔離級別，並經過舉例的方式說明不一樣的級別能解決什麼樣的讀現象。而且介紹了在關係型數據庫中不一樣的隔離級別的實現原理。sql

在DBMS中，事務保證了一個操做序列能夠所有都執行或者所有都不執行（原子性），從一個狀態轉變到另一個狀態（一致性）。因爲事務知足久性。因此一旦事務被提交以後，數據就可以被持久化下來，又由於事務是知足隔離性的，因此，當多個事務同時處理同一個數據的時候，多個事務直接是互不影響的，因此，在多個事務併發操做的過程當中，若是控制很差隔離級別，就有可能產生髒讀、不可重複讀或者幻讀等讀現象。數據庫

在數據庫事務的ACID四個屬性中，隔離性是一個最常放鬆的一個。能夠在數據操做過程當中利用數據庫的鎖機制或者多版本併發控制機制獲取更高的隔離等級。可是，隨着數據庫隔離級別的提升，數據的併發能力也會有所降低。因此，如何在併發性和隔離性之間作一個很好的權衡就成了一個相當重要的問題。併發

在軟件開發中，幾乎每類這樣的問題都會有多種最佳實踐來供咱們參考，不少DBMS定義了多個不一樣的「事務隔離等級」來控制鎖的程度和併發能力。ide

ANSI/ISO SQL定義的標準隔離級別有四種，從高到底依次爲：可序列化(Serializable)、可重複讀(Repeatable reads)、提交讀(Read committed)、未提交讀(Read uncommitted)。spa

下面將依次介紹這四種事務隔離級別的概念、用法以及解決了哪些問題（讀現象）翻譯

未提交讀(Read uncommitted)code

未提交讀(READ UNCOMMITTED)是最低的隔離級別。經過名字咱們就能夠知道，在這種事務隔離級別下，一個事務能夠讀到另一個事務未提交的數據。索引

未提交讀的數據庫鎖狀況（實現原理）事務

事務在讀數據的時候並未對數據加鎖。開發

務在修改數據的時候只對數據增長行級共享鎖。
現象：

事務1讀取某行記錄時，事務2也能對這行記錄進行讀取、更新（由於事務一併未對數據增長任何鎖）

當事務2對該記錄進行更新時，事務1再次讀取該記錄，能讀到事務2對該記錄的修改版本（由於事務二隻增長了共享讀鎖，事務一能夠再增長共享讀鎖讀取數據），即便該修改還沒有被提交。

事務1更新某行記錄時，事務2不能對這行記錄作更新，直到事務1結束。（由於事務一對數據增長了共享讀鎖，事務二不能增長排他寫鎖進行數據的修改）

舉例

事務一 事務二
/* Query 1 */
 SELECT age FROM users WHERE id = 1;  
/* will read 20 */  

 /* Query 2 */ 
UPDATE users SET age = 21 WHERE id = 1;
 /* No commit here */
 /* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 21 */  

 ROLLBACK;
/* lock-based DIRTY READ */

下面仍是借用我在數據庫的讀現象淺析一文中舉的例子來講明在未提交讀的隔離級別中兩個事務之間的隔離狀況。

事務一共查詢了兩次，在兩次查詢的過程當中，事務二對數據進行了修改，並未提交（commit）。可是事務一的第二次查詢查到了事務二的修改結果。在數據庫的讀現象淺析中咱們介紹過，這種現象咱們稱之爲髒讀。

因此，未提交讀會致使髒讀

提交讀(Read committed)

提交讀(READ COMMITTED)也能夠翻譯成讀已提交，經過名字也能夠分析出，在一個事務修改數據過程當中，若是事務還沒提交，其餘事務不能讀該數據。

提交讀的數據庫鎖狀況

事務對當前被讀取的數據加行級共享鎖（當讀到時才加鎖），一旦讀完該行，當即釋放該行級共享鎖；

事務在更新某數據的瞬間（就是發生更新的瞬間），必須先對其加行級排他鎖，直到事務結束才釋放。

現象：

事務1在讀取某行記錄的整個過程當中，事務2均可以對該行記錄進行讀取（由於事務一對該行記錄增長行級共享鎖的狀況下，事務二一樣能夠對該數據增長共享鎖來讀數據。）。

事務1讀取某行的一瞬間，事務2不能修改該行數據，可是，只要事務1讀取完改行數據，事務2就能夠對該行數據進行修改。（事務一在讀取的一瞬間會對數據增長共享鎖，任何其餘事務都不能對該行數據增長排他鎖。可是事務一隻要讀完該行數據，就會釋放行級共享鎖，一旦鎖釋放，事務二就能夠對數據增長排他鎖並修改數據）

事務1更新某行記錄時，事務2不能對這行記錄作更新，直到事務1結束。（事務一在更新數據的時候，會對該行數據增長排他鎖，知道事務結束纔會釋放鎖，因此，在事務二沒有提交以前，事務一都能不對數據增長共享鎖進行數據的讀取。因此，提交讀能夠解決髒讀的現象）

舉例

事務一 事務二
/* Query 1 */
 SELECT * FROM users WHERE id = 1;  

 /* Query 2 */ 
UPDATE users SET age = 21 WHERE id = 1;
 COMMIT;
 /* in multiversion concurrency control, or lock-based READ COMMITTED */ 
 /* Query 1 */
SELECT * FROM users WHERE id = 1;
 COMMIT; 
/*lock-based REPEATABLE READ */

在提交讀隔離級別中，在事務二提交以前，事務一不能讀取數據。只有在事務二提交以後，事務一才能讀數據。

可是從上面的例子中咱們也看到，事務一兩次讀取的結果並不一致，因此提交讀不能解決不可重複讀的讀現象。

簡而言之，提交讀這種隔離級別保證了讀到的任何數據都是提交的數據，避免了髒讀(dirty reads)。可是不保證事務從新讀的時候能讀到相同的數據，由於在每次數據讀完以後其餘事務能夠修改剛纔讀到的數據。

可重複讀(Repeatable reads)

可重複讀(REPEATABLE READS),因爲提交讀隔離級別會產生不可重複讀的讀現象。因此，比提交讀更高一個級別的隔離級別就能夠解決不可重複讀的問題。這種隔離級別就叫可重複讀（這名字起的是否是很任性！！）

可重複讀的數據庫鎖狀況

事務在讀取某數據的瞬間（就是開始讀取的瞬間），必須先對其加行級共享鎖，直到事務結束才釋放；

事務在更新某數據的瞬間（就是發生更新的瞬間），必須先對其加行級排他鎖，直到事務結束才釋放。

現象

事務1在讀取某行記錄的整個過程當中，事務2均可以對該行記錄進行讀取（由於事務一對該行記錄增長行級共享鎖的狀況下，事務二一樣能夠對該數據增長共享鎖來讀數據。）。

事務1在讀取某行記錄的整個過程當中，事務2都不能修改該行數據（事務一在讀取的整個過程會對數據增長共享鎖，直到事務提交纔會釋放鎖，因此整個過程當中，任何其餘事務都不能對該行數據增長排他鎖。因此，可重複讀可以解決不可重複讀的讀現象）

事務1更新某行記錄時，事務2不能對這行記錄作更新，直到事務1結束。（事務一在更新數據的時候，會對該行數據增長排他鎖，知道事務結束纔會釋放鎖，因此，在事務二沒有提交以前，事務一都能不對數據增長共享鎖進行數據的讀取。因此，提交讀能夠解決髒讀的現象）

舉例

事務一 事務二
/* Query 1 */
 SELECT * FROM users WHERE id = 1; 
 COMMIT;    

 /* Query 2 */ 
UPDATE users SET age = 21 WHERE id = 1;
 COMMIT;
 /* in multiversion concurrency control, or lock-based READ COMMITTED */

在上面的例子中，只有在事務一提交以後，事務二才能更改該行數據。因此，只要在事務一從開始到結束的這段時間內，不管他讀取該行數據多少次，結果都是同樣的。

從上面的例子中咱們能夠獲得結論：可重複讀隔離級別能夠解決不可重複讀的讀現象。可是可重複讀這種隔離級別中，還有另一種讀現象他解決不了，那就是幻讀。看下面的例子：

事務一 事務二
/* Query 1 */
 SELECT * FROM users WHERE age BETWEEN 10 AND 30;   

 /* Query 2 */ 
INSERT INTO users VALUES ( 3, 'Bob', 27 );
 COMMIT;
 /* Query 1 */
SELECT * FROM users WHERE age BETWEEN 10 AND 30;

上面的兩個事務執行狀況及現象以下：

1.事務一的第一次查詢條件是age BETWEEN 10 AND 30;若是這是有十條記錄符合條件。這時，他會給符合條件的這十條記錄增長行級共享鎖。任何其餘事務沒法更改這十條記錄。

2.事務二執行一條sql語句，語句的內容是向表中插入一條數據。由於此時沒有任何事務對錶增長表級鎖，因此，該操做能夠順利執行。

3.事務一再次執行SELECT * FROM users WHERE age BETWEEN 10 AND 30;時，結果返回的記錄變成了十一條，比剛剛增長了一條，增長的這條正是事務二剛剛插入的那條。

因此，事務一的兩次範圍查詢結果並不相同。這也就是咱們提到的幻讀。

可序列化(Serializable)

可序列化(Serializable)是最高的隔離級別，前面提到的全部的隔離級別都沒法解決的幻讀，在可序列化的隔離級別中能夠解決。

咱們說過，產生幻讀的緣由是事務一在進行範圍查詢的時候沒有增長範圍鎖(range-locks：給SELECT 的查詢中使用一個「WHERE」子句描述範圍加鎖），因此致使幻讀。

可序列化的數據庫鎖狀況

事務在讀取數據時，必須先對其加表級共享鎖，直到事務結束才釋放；

事務在更新數據時，必須先對其加表級排他鎖，直到事務結束才釋放。

現象

事務1正在讀取A表中的記錄時，則事務2也能讀取A表，但不能對A表作更新、新增、刪除，直到事務1結束。(由於事務一對錶增長了表級共享鎖，其餘事務只能增長共享鎖讀取數據，不能進行其餘任何操做）

事務1正在更新A表中的記錄時，則事務2不能讀取A表的任意記錄，更不可能對A表作更新、新增、刪除，直到事務1結束。（事務一對錶增長了表級排他鎖，其餘事務不能對錶增長共享鎖或排他鎖，也就沒法進行任何操做）

雖然可序列化解決了髒讀、不可重複讀、幻讀等讀現象。可是序列化事務會產生如下效果：

1.沒法讀取其它事務已修改但未提交的記錄。

2.在當前事務完成以前，其它事務不能修改目前事務已讀取的記錄。

3.在當前事務完成以前，其它事務所插入的新記錄，其索引鍵值不能在當前事務的任何語句所讀取的索引鍵範圍中。

四種事務隔離級別從隔離程度上愈來愈高，但同時在併發性上也就愈來愈低。之因此有這麼幾種隔離級別，就是爲了方便開發人員在開發過程當中根據業務須要選擇最合適的隔離級別。