徹底理解事務的4個隔離級別

簡介

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

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

資料庫事務的隔離級別有4個，由低到高依次為Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別可以逐個解決臟讀、不可重覆讀、幻讀這幾類問題。

註意：我們討論隔離級別的場景，主要是在多個事務併發的情況下，因此，接下來的講解都圍繞事務併發。

Read uncommitted

讀未提交，顧名思義，就是一個事務可以讀取另一個未提交事務的數據。

事例：老闆要給程式員發工資，程式員的工資是3.6萬/月。但是發工資時老闆不小心按錯了數字，按成3.9萬/月，該錢已經打到程式員的戶口，但是事務還沒有提交，就在這時，程式員去查看自己這個月的工資，發現比往常多了3千元，以為漲工資了非常高興。但是老闆及時發現了不對，馬上回滾差點就提交了的事務，將數字改成3.6萬再提交。

分析：這種情況就是臟讀，兩個併發的事務，"事務A"：領導發工資、"事務B"：程式員查看工資，事務B讀取了事務A尚未提交的數據實際程式員這個月的工資還是3.6萬，但是程式員看到的是3.9萬。

未提交讀的資料庫鎖情況（實現原理）

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

事務在修改數據的時候只對數據增加行級共用鎖。

表現：

• 事務1讀取某行記錄時，事務2也能對這行記錄進行讀取、更新；當事務2對該記錄進行更新時，事務1再次讀取該記錄，能讀到事務2對該記錄的修改版本，即使該修改尚未被提交。
• 事務1更新某行記錄時，事務2不能對這行記錄做更新，直到事務1結束。

舉例

設置 set session transaction isolation level read uncommitted;

        set autocommit=0; 

下麵還是借用我在資料庫的讀現象淺析一文中舉的例子來說明在未提交讀的隔離級別中兩個事務之間的隔離情況。

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

所以，未提交讀會導致臟讀

事務1更新某行記錄時，事務2不能對這行記錄做更新，直到事務1結束：

可以看到右邊更新一個記錄時，還沒有提交；

此時，左邊的事務二也對這條記錄更新，會阻塞。

Read committed

提交讀，顧名思義，就是一個事務要等另一個事務提交後才能讀取數據。

事例：程式員拿著信用卡去享受生活（卡裡當然是只有3.6萬），當他埋單時（程式員事務開啟），收費系統事先檢測到他的卡裡有3.6萬，就在這個時候！！程式員的妻子要把錢全部轉出充當家用，並提交。當收費系統準備扣款時，再檢測卡裡的金額，發現已經沒錢了（第二次檢測金額當然要等待妻子轉出金額事務提交完）。程式員就會很鬱悶，明明卡裡是有錢的…

分析：這就是提交讀，若有事務對數據進行更新（UPDATE）操作時，讀操作事務要等待這個更新操作事務提交後才能讀取數據，可以解決臟讀問題。但在這個事例中，出現了一個事務範圍內兩個相同的查詢卻返回了不同數據，這就是不可重覆讀。

提交讀的資料庫鎖情況(實現原理)

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

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

舉例

**在事務二沒有提交之前，事務一是不能更改這條記錄的，也不可以加共用鎖(lock in share mode)。只能執行普通的查詢。

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

但是從上面的例子中我們也看到，事務一兩次讀取的結果並不一致，所以提交讀不能解決不可重覆讀的讀現象。

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

Repeatable read

重覆讀，就是在開始讀取數據（事務開啟）時，不再允許修改操作

事例：程式員拿著信用卡去享受生活（卡裡當然是只有3.6萬），當他買單時（事務開啟，不允許其他事務的UPDATE修改操作），收費系統事先檢測到他的卡裡有3.6萬。這個時候他的妻子不能轉出金額了。接下來收費系統就可以扣款了。

分析：重覆讀可以解決不可重覆讀問題。寫到這裡，應該明白的一點就是，不可重覆讀對應的是修改，即UPDATE操作。但是可能還會有幻讀問題。因為幻讀問題對應的是插入INSERT操作，而不是UPDATE操作。

可重覆讀的資料庫鎖情況

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

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

現象

事務1在讀取某行記錄的整個過程中，事務2都可以對該行記錄進行讀取（因為事務一對該行記錄增加行級共用鎖的情況下，事務二同樣可以對該數據增加共用鎖來讀數據。）。

事務1在讀取某行記錄的整個過程中，事務2都不能修改該行數據（事務一在讀取的整個過程會對數據增加共用鎖，直到事務提交才會釋放鎖，所以整個過程中，任何其他事務都不能對該行數據增加排他鎖。所以，可重覆讀能夠解決不可重覆讀的讀現象）

舉例

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

幻讀

事例：程式員某一天去消費，花了2千元，然後他的妻子去查看他今天的消費記錄（全表掃描FTS，妻子事務開啟），看到確實是花了2千元，就在這個時候，程式員花了1萬買了一部電腦，即新增INSERT了一條消費記錄，並提交。當妻子列印程式員的消費記錄清單時（妻子事務提交），發現花了1.2萬元，似乎出現了幻覺，這就是幻讀。

事務一：妻子去查看消費記錄，事務一的兩次範圍查詢結果並不相同。這也就是我們提到的幻讀。

可重覆讀隔離級別可以解決不可重覆讀的讀現象，但是解決不了幻讀。解決幻讀需要序列化。

Serializable 序列化

Serializable 是最高的事務隔離級別，在該級別下，事務串列化順序執行，可以避免臟讀、不可重覆讀與幻讀。但是這種事務隔離級別效率低下，比較耗資料庫性能，一般不使用。

可序列化的資料庫鎖情況

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

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

值得一提的是：大多數資料庫預設的事務隔離級別是Read committed，比如Sql Server , Oracle。MySQL的預設隔離級別是Repeatable read。

 參考文章：

深入分析事務的隔離級別

理解事務的4種隔離級別

轉發請註明出處：http://www.cnblogs.com/jycboy/p/transaction.html