SQL標(biāo)準(zhǔn)定義了4類隔離級別，包括了一些具體規(guī)則，用來限定事務(wù)內(nèi)外的哪些改變是可見的，哪些是不可見的。低級別的隔離級一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。
Read Uncommitted（讀取未提交內(nèi)容）
       在該隔離級別，所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。本隔離級別很少用于實際應(yīng)用，因為它的性能也不比其他級別好多少。讀取未提交的數(shù)據(jù)，也被稱之為臟讀（Dirty Read）。
Read Committed（讀取提交內(nèi)容）
       這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別（但不是MySQL默認的）。它滿足了隔離的簡單定義：一個事務(wù)只能看見已經(jīng)提交事務(wù)所做的改變。這種隔離級別 也支持所謂的不可重復(fù)讀（Nonrepeatable Read），因為同一事務(wù)的其他實例在該實例處理其間可能會有新的commit，所以同一select可能返回不同結(jié)果。
Repeatable Read（可重讀）
       這是MySQL的默認事務(wù)隔離級別，它確保同一事務(wù)的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行。不過理論上，這會導(dǎo)致另一個棘手的問題：幻讀 （Phantom Read）。簡單的說，幻讀指當(dāng)用戶讀取某一范圍的數(shù)據(jù)行時，另一個事務(wù)又在該范圍內(nèi)插入了新行，當(dāng)用戶再讀取該范圍的數(shù)據(jù)行時，會發(fā)現(xiàn)有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本并發(fā)控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。
Serializable（可串行化） 
       這是最高的隔離級別，它通過強制事務(wù)排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數(shù)據(jù)行上加上共享鎖。在這個級別，可能導(dǎo)致大量的超時現(xiàn)象和鎖競爭。
         這四種隔離級別采取不同的鎖類型來實現(xiàn)，若讀取的是同一個數(shù)據(jù)的話，就容易發(fā)生問題。例如：

•          臟讀(Drity Read)：某個事務(wù)已更新一份數(shù)據(jù)，另一個事務(wù)在此時讀取了同一份數(shù)據(jù)，由于某些原因，前一個RollBack了操作，則后一個事務(wù)所讀取的數(shù)據(jù)就會是不正確的。
•          不可重復(fù)讀(Non-repeatable read):在一個事務(wù)的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中間插入了一個事務(wù)更新的原有的數(shù)據(jù)。
•          幻讀(Phantom Read):在一個事務(wù)的兩次查詢中數(shù)據(jù)筆數(shù)不一致，例如有一個事務(wù)查詢了幾列(Row)數(shù)據(jù)，而另一個事務(wù)卻在此時插入了新的幾列數(shù)據(jù)，先前的事務(wù)在接下來的查詢中，就會發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

         在MySQL中，實現(xiàn)了這四種隔離級別，分別有可能產(chǎn)生問題如下所示：

MySQL事務(wù)隔離級別對其性能的影響
MySQL默認工作在級別三下。我們知道事務(wù)隔離是為了避免并發(fā)操作相互影響而導(dǎo)數(shù)據(jù)的不一致性。所以為了保證數(shù)據(jù)的一致性，就引入了事務(wù)隔離的功能。以上四個級別的對數(shù)據(jù)的一致性保護是逐步提高的。級別4對事務(wù)的隔離效果最好，但是性能最差，一般不再生產(chǎn)環(huán)境中使用。
下面通過實例來檢驗不同級別下MySQL性能收到的影響。我的實驗環(huán)境是：Redhat5.8+MySQL5.5
首先我們這里啟用兩個session：
1、驗證級別一的特性
我們在session A上進行的操作為：

在session B上的操作同session A，這里不再附上截圖。
       接下來我們就通過一系列的實驗來觀察READ-UNCOMMITTED到底是什么，它到底有什么特性，對我們的操作到底有什么影響。首先，我們可以看到表中的初始數(shù)據(jù)如下：

接下來我們在sessionA上更改其中的一條記錄，更改結(jié)果如下：

注意：我們在上面啟用了事務(wù)，但是我們在這里并沒有進行commit操作。
 
接下來我們在sessionB中對剛才改過的表進行select查詢，查詢結(jié)果如下：

我們可以清楚的看到，雖然我們并沒有對session A的結(jié)果進行commit，但是結(jié)果確實已經(jīng)改變。因此在這種級別下，沒有提交的操作會對數(shù)據(jù)的一致性有影響。因此，如果我們此時在session A上對上述操作進行回滾，我們會發(fā)現(xiàn)此時session B上的結(jié)果又回到原來最初的結(jié)果，這樣就造成了數(shù)據(jù)的不一致性，這也稱為數(shù)據(jù)的幻讀現(xiàn)象，看起來是很詭異的事情。因此在某些場景下，我們應(yīng)該避免這種現(xiàn)象的產(chǎn)生。但是這種級別也不是沒有它的用武之地，比如當(dāng)我們有大量數(shù)據(jù)需要寫入，而讀操作很少的時候，就適合用這種模式。
可以看到session A回滾后，session B中的數(shù)據(jù)又變成最初的樣子，這也稱為幻讀：

2、驗證級別READ COMMITTED特性
       首先把session A和session B的隔離級別都改為READ-COMMITTED，并且全部都開啟事務(wù)，操作如下：

接下來我們查看tutors表的初始狀態(tài)信息：

然后我們依然是對數(shù)據(jù)進行更新操作，更新之后仍然沒有commit。我們可以看到在sessionA中，結(jié)果已經(jīng)發(fā)生改變：

此時我們在session B中查看，發(fā)現(xiàn)結(jié)果依然維持不變：

但是，如果我們此時在session A中進行commit操作，我們就會發(fā)現(xiàn)，sessionB此時查詢就會發(fā)生改變，這樣也造成了數(shù)據(jù)的前后不一致性，也是數(shù)據(jù)的幻讀：

3、數(shù)據(jù)的可重讀
       數(shù)據(jù)的可重讀，也叫作REPEATABLE-READ，這是MySQL默認采用的事務(wù)隔離級別，有其優(yōu)勢，但是仍然沒有從根本上解決數(shù)據(jù)的一致性問題。首先，還是讓我們來測試一下，在這種級別下MySQL到底是如何工作的，又有哪些特性，我們又該怎樣去操作。
       我們先把REPEATABLE-READ的環(huán)境設(shè)置好，具體的操作方法如下：

然后我們在查看其初始數(shù)據(jù)，其結(jié)果如下：

我們在session A中修改數(shù)據(jù)，并進行commit，修改后的結(jié)果如下：

然后我們在session B中進行查看發(fā)現(xiàn)結(jié)果仍然沒有任何改變：

這就是可重讀的特性，只要本次會話不提交，盡管對方修改，但是結(jié)果仍然不變，只有在session B中也進行commit操作，所作的修改才會在sessionB中生效。
 
4、seriabliable
這個級別是事務(wù)隔離安全性最好的，但是也是性能最差的，因為這個級別所有的操作都是串行進行的。一個操作沒有提交，另一個受到影響的操作會處于阻塞狀態(tài)。
為了驗證這種效果，我們先把環(huán)境設(shè)置好，具體為在session A和session B同時設(shè)置如下：

在session A 中對其任意字段進行修改，并且沒有進行commit操作。此時揮發(fā)現(xiàn)sessionB中的查詢操作會一直處于阻塞狀態(tài)：

這就設(shè)串行化隔離的效果，也是為什么串行化隔離并發(fā)能力差的原因。

最新評論