SQL標(biāo)準(zhǔn)定義了4類隔離級(jí)別，包括了一些具體規(guī)則，用來限定事務(wù)內(nèi)外的哪些改變是可見的，哪些是不可見的。低級(jí)別的隔離級(jí)一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。
Read Uncommitted（讀取未提交內(nèi)容）
在該隔離級(jí)別，所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。本隔離級(jí)別很少用于實(shí)際應(yīng)用，因?yàn)樗男阅芤膊槐绕渌?jí)別好多少。讀取未提交的數(shù)據(jù)，也被稱之為臟讀（Dirty Read）。
Read Committed（讀取提交內(nèi)容）
這是大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)的默認(rèn)隔離級(jí)別（但不是MySQL默認(rèn)的）。它滿足了隔離的簡(jiǎn)單定義：一個(gè)事務(wù)只能看見已經(jīng)提交事務(wù)所做的改變。這種隔離級(jí)別 也支持所謂的不可重復(fù)讀（Nonrepeatable Read），因?yàn)橥皇聞?wù)的其他實(shí)例在該實(shí)例處理其間可能會(huì)有新的commit，所以同一select可能返回不同結(jié)果。
Repeatable Read（可重讀）
這是MySQL的默認(rèn)事務(wù)隔離級(jí)別，它確保同一事務(wù)的多個(gè)實(shí)例在并發(fā)讀取數(shù)據(jù)時(shí)，會(huì)看到同樣的數(shù)據(jù)行。不過理論上，這會(huì)導(dǎo)致另一個(gè)棘手的問題：幻讀 （Phantom Read）。簡(jiǎn)單的說，幻讀指當(dāng)用戶讀取某一范圍的數(shù)據(jù)行時(shí)，另一個(gè)事務(wù)又在該范圍內(nèi)插入了新行，當(dāng)用戶再讀取該范圍的數(shù)據(jù)行時(shí)，會(huì)發(fā)現(xiàn)有新的“幻影” 行。InnoDB和Falcon存儲(chǔ)引擎通過多版本并發(fā)控制（MVCC，Multiversion Concurrency Control）機(jī)制解決了該問題。
Serializable（可串行化）
這是最高的隔離級(jí)別，它通過強(qiáng)制事務(wù)排序，使之不可能相互沖突，從而解決幻讀問題。簡(jiǎn)言之，它是在每個(gè)讀的數(shù)據(jù)行上加上共享鎖。在這個(gè)級(jí)別，可能導(dǎo)致大量的超時(shí)現(xiàn)象和鎖競(jìng)爭(zhēng)。
這四種隔離級(jí)別采取不同的鎖類型來實(shí)現(xiàn)，若讀取的是同一個(gè)數(shù)據(jù)的話，就容易發(fā)生問題。例如：
- 臟讀(Drity Read)：某個(gè)事務(wù)已更新一份數(shù)據(jù)，另一個(gè)事務(wù)在此時(shí)讀取了同一份數(shù)據(jù)，由于某些原因，前一個(gè)RollBack了操作，則后一個(gè)事務(wù)所讀取的數(shù)據(jù)就會(huì)是不正確的。
- 不可重復(fù)讀(Non-repeatable read):在一個(gè)事務(wù)的兩次查詢之中數(shù)據(jù)不一致，這可能是兩次查詢過程中間插入了一個(gè)事務(wù)更新的原有的數(shù)據(jù)。
- 幻讀(Phantom Read):在一個(gè)事務(wù)的兩次查詢中數(shù)據(jù)筆數(shù)不一致，例如有一個(gè)事務(wù)查詢了幾列(Row)數(shù)據(jù)，而另一個(gè)事務(wù)卻在此時(shí)插入了新的幾列數(shù)據(jù)，先前的事務(wù)在接下來的查詢中，就會(huì)發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。
在MySQL中，實(shí)現(xiàn)了這四種隔離級(jí)別，分別有可能產(chǎn)生問題如下所示：
MySQL事務(wù)隔離級(jí)別對(duì)其性能的影響
MySQL默認(rèn)工作在級(jí)別三下。我們知道事務(wù)隔離是為了避免并發(fā)操作相互影響而導(dǎo)數(shù)據(jù)的不一致性。所以為了保證數(shù)據(jù)的一致性，就引入了事務(wù)隔離的功能。以上四個(gè)級(jí)別的對(duì)數(shù)據(jù)的一致性保護(hù)是逐步提高的。級(jí)別4對(duì)事務(wù)的隔離效果最好，但是性能最差，一般不再生產(chǎn)環(huán)境中使用。
下面通過實(shí)例來檢驗(yàn)不同級(jí)別下MySQL性能收到的影響。我的實(shí)驗(yàn)環(huán)境是：Redhat5.8+MySQL5.5
首先我們這里啟用兩個(gè)session：
1、驗(yàn)證級(jí)別一的特性
我們?cè)趕ession A上進(jìn)行的操作為：
在session B上的操作同session A，這里不再附上截圖。
接下來我們就通過一系列的實(shí)驗(yàn)來觀察READ-UNCOMMITTED到底是什么，它到底有什么特性，對(duì)我們的操作到底有什么影響。首先，我們可以看到表中的初始數(shù)據(jù)如下：
接下來我們?cè)趕essionA上更改其中的一條記錄，更改結(jié)果如下：
注意：我們?cè)谏厦鎲⒂昧耸聞?wù)，但是我們?cè)谶@里并沒有進(jìn)行commit操作。
接下來我們?cè)趕essionB中對(duì)剛才改過的表進(jìn)行select查詢，查詢結(jié)果如下：
我們可以清楚的看到，雖然我們并沒有對(duì)session A的結(jié)果進(jìn)行commit，但是結(jié)果確實(shí)已經(jīng)改變。因此在這種級(jí)別下，沒有提交的操作會(huì)對(duì)數(shù)據(jù)的一致性有影響。因此，如果我們此時(shí)在session A上對(duì)上述操作進(jìn)行回滾，我們會(huì)發(fā)現(xiàn)此時(shí)session B上的結(jié)果又回到原來最初的結(jié)果，這樣就造成了數(shù)據(jù)的不一致性，這也稱為數(shù)據(jù)的幻讀現(xiàn)象，看起來是很詭異的事情。因此在某些場(chǎng)景下，我們應(yīng)該避免這種現(xiàn)象的產(chǎn)生。但是這種級(jí)別也不是沒有它的用武之地，比如當(dāng)我們有大量數(shù)據(jù)需要寫入，而讀操作很少的時(shí)候，就適合用這種模式。
可以看到session A回滾后，session B中的數(shù)據(jù)又變成最初的樣子，這也稱為幻讀：
2、驗(yàn)證級(jí)別READ COMMITTED特性
首先把session A和session B的隔離級(jí)別都改為READ-COMMITTED，并且全部都開啟事務(wù)，操作如下：
接下來我們查看tutors表的初始狀態(tài)信息：
然后我們依然是對(duì)數(shù)據(jù)進(jìn)行更新操作，更新之后仍然沒有commit。我們可以看到在sessionA中，結(jié)果已經(jīng)發(fā)生改變：
此時(shí)我們?cè)趕ession B中查看，發(fā)現(xiàn)結(jié)果依然維持不變：
但是，如果我們此時(shí)在session A中進(jìn)行commit操作，我們就會(huì)發(fā)現(xiàn)，sessionB此時(shí)查詢就會(huì)發(fā)生改變，這樣也造成了數(shù)據(jù)的前后不一致性，也是數(shù)據(jù)的幻讀：
3、數(shù)據(jù)的可重讀
數(shù)據(jù)的可重讀，也叫作REPEATABLE-READ，這是MySQL默認(rèn)采用的事務(wù)隔離級(jí)別，有其優(yōu)勢(shì)，但是仍然沒有從根本上解決數(shù)據(jù)的一致性問題。首先，還是讓我們來測(cè)試一下，在這種級(jí)別下MySQL到底是如何工作的，又有哪些特性，我們又該怎樣去操作。
我們先把REPEATABLE-READ的環(huán)境設(shè)置好，具體的操作方法如下：
然后我們?cè)诓榭雌涑跏紨?shù)據(jù)，其結(jié)果如下：
我們?cè)趕ession A中修改數(shù)據(jù)，并進(jìn)行commit，修改后的結(jié)果如下：
然后我們?cè)趕ession B中進(jìn)行查看發(fā)現(xiàn)結(jié)果仍然沒有任何改變：
這就是可重讀的特性，只要本次會(huì)話不提交，盡管對(duì)方修改，但是結(jié)果仍然不變，只有在session B中也進(jìn)行commit操作，所作的修改才會(huì)在sessionB中生效。
4、seriabliable
這個(gè)級(jí)別是事務(wù)隔離安全性最好的，但是也是性能最差的，因?yàn)檫@個(gè)級(jí)別所有的操作都是串行進(jìn)行的。一個(gè)操作沒有提交，另一個(gè)受到影響的操作會(huì)處于阻塞狀態(tài)。
為了驗(yàn)證這種效果，我們先把環(huán)境設(shè)置好，具體為在session A和session B同時(shí)設(shè)置如下：
在session A 中對(duì)其任意字段進(jìn)行修改，并且沒有進(jìn)行commit操作。此時(shí)揮發(fā)現(xiàn)sessionB中的查詢操作會(huì)一直處于阻塞狀態(tài)：
這就設(shè)串行化隔離的效果，也是為什么串行化隔離并發(fā)能力差的原因。
