MySQL事務隔離級別

最近恰好閒下來，本身事務隔離級別不是太熟悉，因此寫篇文章記錄下來。

SQL定義了四類隔離級別，包括了一些具體規則，用來限定事務內外的哪些改變是可見的，哪些是不可見的。低級別的隔離級通常支持更高的併發處理，並擁有更低的系統開銷。

其次咱們先了解下這四類隔離級別的定義：

Read Uncommitted（讀取未提交內容）

       在該隔離級別，全部事務均可以看到其餘未提交事務的執行結果。本隔離級別不多用於實際應用，由於它的性能也不比其餘級別好多少。讀取未提交的數據，也被稱之爲髒讀（Dirty Read）。
Read Committed（讀取提交內容）

       這是大多數數據庫系統的默認隔離級別（但不是MySQL默認的）。它知足了隔離的簡單定義：一個事務只能看見已經提交事務所作的改變。這種隔離級別 也支持所謂的不可重複讀（Nonrepeatable Read），由於同一事務的其餘實例在該實例處理其間可能會有新的commit，因此同一select可能返回不一樣結果。
Repeatable Read（可重讀）

       這是MySQL的默認事務隔離級別，它確保同一事務的多個實例在併發讀取數據時，會看到一樣的數據行。不過理論上，這會致使另外一個棘手的問題：幻讀 （Phantom Read）。簡單的說，幻讀指當用戶讀取某一範圍的數據行時，另外一個事務又在該範圍內插入了新行，當用戶再讀取該範圍的數據行時，會發現有新的「幻影」 行。InnoDB和Falcon存儲引擎經過多版本併發控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。

Serializable（可串行化） 
       這是最高的隔離級別，它經過強制事務排序，使之不可能相互衝突，從而解決幻讀問題。簡言之，它是在每一個讀的數據行上加上共享鎖。在這個級別，可能致使大量的超時現象和鎖競爭。

         這四種隔離級別採起不一樣的鎖類型來實現，若讀取的是同一個數據的話，就容易發生問題。例如：

         髒讀(Drity Read)：某個事務已更新一份數據，另外一個事務在此時讀取了同一份數據，因爲某些緣由，前一個RollBack了操做，則後一個事務所讀取的數據就會是不正確的。

         不可重複讀(Non-repeatable read):在一個事務的兩次查詢之中數據不一致，這多是兩次查詢過程當中間插入了一個事務更新的原有的數據。

         幻讀(Phantom Read):在一個事務的兩次查詢中數據筆數不一致，例若有一個事務查詢了幾列(Row)數據，而另外一個事務卻在此時插入了新的幾列數據，先前的事務在接下來的查詢中，就會發現有幾列數據是它先前所沒有的

在MySQL中，實現這四類隔離級別，分別有可能產生問題以下所示：

下面，利用MySQL來演示以上這四類隔離級別，首先須要知道如下指令的含義：

SELECT @@global.tx_isolation; ／／全局，從對那個點開始的全部連接

SELECT @@session.tx_isolation; ／／當前鏈接上執行的事務設置默認事務級別

SELECT @@tx_isolation;／／是爲下一個（未開始）事務設置隔離級別

set global transaction isolation level read committed;／／全局事務隔離級別

set session transaction isolation level read committed;／／當前連接事務隔離級別

首先我建立tx表，如圖所示

而後分別對其四類事務級別逐一分析，具體以下：

一）、將A的隔離級別設置爲read uncommitted(未提交讀)

客戶端A

客戶端B更新數據

客戶端A

從上面的實驗能夠看出，客戶端B更新了一條記錄，可是沒有提交，此時客戶端A能夠查詢出未提交記錄。形成髒讀現象。未提交讀是最低的隔離級別。

二）、將客戶端A的事務隔離級別設置爲read committed(已提交讀)

客戶端A

客戶端B，進行更新數據

而後，客戶端A查詢結果，第一次查詢是在commit以前其結果集無變化，第二次查詢是在commit以後，其結果集發生變化

由此能夠看出，已提交讀隔離級別解決了髒讀的問題，可是出現了不可重複讀的問題，即事務A在兩次查詢的數據不一致，由於在兩次查詢之間事務B更新了一條數據。已提交讀只容許讀取已提交的記錄，但不要求可重複讀。

(三)、將A的隔離級別設置爲repeatable read(可重複讀)

客戶端A，將隔離級別設置爲可重複讀，而後開啓事務，進行查詢

客戶端B，開啓事務，並進行修改

此時查看客戶端A，進行查詢數據並未改變

此時B提交事務，並查詢

而後查看A，數據仍是沒有變化

A進行commit以後，發現數據改變了

由以上能夠得出，可重複讀隔離級別只容許讀取已提交記錄，並且在一個事務兩次讀取一個記錄期間，其餘事務不能更新該記錄。但該事務不要求與其餘事務可串行化。例如，當一個事務能夠找到由一個已提交事務更新的記錄，可是可能產生幻讀問題(注意是可能，由於數據庫對隔離級別的實現有所差異)。像以上的實驗，就沒有出現數據幻讀的問題。

繼續驗證，A開啓事務，並對其修改

B開啓事務，並對其進行修改，修改被掛起，直到超時，但對另一條的修改卻能夠成功，說明客戶端A在對其修改的時候，對錶加上了行共享鎖。

在事務中對某條記錄做修改時，會對記錄加上行共享鎖，直到結束才釋放。

(四)、將A的隔離級別設置爲 可串行化 (Serializable)

客戶端A，首先設置隔離級別

而後開啓事務，進行查詢

此時打開客戶端B，進行查詢，發現能夠正常查詢

此時開啓事務，對客戶端B進行修改update操做，B開啓事務，並對記錄做修改，此時因爲A並未提交，因此B一直處於等待的狀態，直到最後超時。說明事務A作對錶進行作查詢的時候，對錶加上了共享鎖！

serializable徹底鎖定字段，若一個事務來查詢同一份數據就必須等待，直到前一個事務完成並解除鎖定爲止 。是完整的隔離級別，會鎖定對應的數據表格，於是會有效率的問題。