前言：
Mysql支持MyISAM和InnoDB兩種存儲引擎，區(qū)別在此就不詳細說明。此篇是講述事務(wù)，所以切記自己的table是InnDB。此處大坑！
在Mysql InnoDB 中，事務(wù)主要有四種隔離級別
- Read uncommitted (未提交讀)
- Read committed (已提交讀)
- Repeatable read (可重復(fù)讀)
- Serializable (可串行化)
在理解四種隔離級別之前，我們需要先了解另外三個名詞：
- 臟讀
- 不可重復(fù)讀
- 幻讀
臟讀
另一個事務(wù)修改了數(shù)據(jù)，但尚未提交，而本事務(wù)中的SELECT會讀到這些未被提交的數(shù)據(jù)。
不重復(fù)讀
解決了臟讀后，會遇到，同一個事務(wù)執(zhí)行過程中，另外一個事務(wù)提交了新數(shù)據(jù)，因此本事務(wù)先后兩次讀到的數(shù)據(jù)結(jié)果會不一致。
幻讀
解決了不重復(fù)讀，保證了同一個事務(wù)里，查詢的結(jié)果都是事務(wù)開始時的狀態(tài)（一致性）。但是，如果另一個事務(wù)同時提交了新數(shù)據(jù)，本事務(wù)再更新時，就會“驚奇的”發(fā)現(xiàn)了這些新數(shù)據(jù)，貌似之前讀到的數(shù)據(jù)是“鬼影”一樣的幻覺。
下面我們就直接來通過實驗來看，Mysql Innodb中，不同的事務(wù)隔離級別，會出現(xiàn)怎么樣的結(jié)果。
首先我們開啟兩個終端，查詢當前MySQL的默認隔離級別:
SELECT @@global.tx_isolation; //查詢?nèi)质聞?wù)
SELECT @@session.tx_isolation; //查詢當前會話事務(wù)
可以看到，默認的隔離級別是：
REPEATABLE-READ
實驗Read uncommitted
我們將會話事務(wù)設(shè)置為：Read uncommitted
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
//測試可以不用設(shè)置全局事務(wù)
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;(這個可以不用設(shè)，只設(shè)置上面一行就可以了進行測試了)
更改完之后，重新查詢事務(wù)：
可以看到，全局事務(wù)已經(jīng)更改為
Read uncommitted
然后，我們首先創(chuàng)建一個測試的數(shù)據(jù)庫test_tx，并插入了2條測試數(shù)據(jù)，如下圖：
然后我們分別開啟事務(wù)，然后我們在B終端中，插入一條數(shù)據(jù)，但是不提交，然后在A終端進行數(shù)據(jù)查詢。
可以看到，我們在B終端insert一條數(shù)據(jù)，但是未進行提交操作(commit)，但是在A事務(wù)中，卻查詢到了。我們稱這種現(xiàn)象叫做臟讀，在實際開發(fā)過程中，我們一般較少使用Read uncommitted隔離級別，這種隔離級別對任何的數(shù)據(jù)操作都不會進行加鎖。
實驗Read committed
首先我們將會話的事務(wù)隔離級別設(shè)置為read committed
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
然后我們用上面相同的方式，進行測試。首先同時將2個終端的事務(wù)開啟：begin;，然后在B終端中插入一條新的數(shù)據(jù)insert into test_tx values(4,"Lee");，但是不提交事務(wù)(commit)，然后在A終端中，查詢數(shù)據(jù)，如圖，我們在A終端中，沒有查詢到剛才插入的這條數(shù)據(jù)。
所以，實驗表明，在Read committed隔離級別，不會出現(xiàn)臟讀的問題。
然后我們繼續(xù)做實驗，看看在Read committed隔離級別中，會不會出現(xiàn)不可重復(fù)讀、幻讀的現(xiàn)象。
我們同時打開兩個終端的事務(wù)，然后在A終端中，查詢當前的數(shù)據(jù)，然后我們在B終端中，將ID為3的數(shù)據(jù)，name修改為Jeff。然后將B終端的事務(wù)提交(commit)，但是A終端不提交事務(wù)，在一個事務(wù)的生命周期內(nèi)，然后查詢數(shù)據(jù)，我們查詢到了剛才B終端修改過的數(shù)據(jù)。也就是說，我們在A終端的一個事務(wù)周期內(nèi)(事務(wù)未commit)，兩次查詢，得到的結(jié)果是不一樣的。
實驗表明，在Read committed隔離級別中，存在不可重復(fù)讀的現(xiàn)象。
我們繼續(xù)做實驗，因為剛才B終端已經(jīng)將事務(wù)提交，所以我們重新打開B終端的事務(wù)，然后我們在B終端中，插入(insert)一條ID為5的新數(shù)據(jù)，并提交事務(wù)。然后我們回到A終端，查詢數(shù)據(jù)，我們同樣可以查詢到剛才B終端新插入的數(shù)據(jù)。也就是說我們在A終端中，三次查詢，得到的結(jié)果都是不一樣的。
實驗表明，在Read committed隔離級別中，存在幻讀的現(xiàn)象。
總結(jié)，在Read committed隔離級別中，可以有效解決臟讀問題，但是有不可重復(fù)讀、幻讀問題，而不可重復(fù)讀和幻讀的差異主要是，不可重復(fù)讀主要是針對修改和刪除操作、幻讀針對插入數(shù)據(jù)操作。
實驗Repeatable read
首先我們將隔離級別更改為Repeatable read
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
然后我們首先實驗，在Repeatable read級別中是否存在臟讀問題，我們首先同時開啟A,B兩個終端的事務(wù)(begin;)，然后在B終端中，插入一條ID為6的數(shù)據(jù)，但是不提交事務(wù)。然后在A終端中進行數(shù)據(jù)查詢，結(jié)果是我們未查詢到剛才插入的數(shù)據(jù)，所以在Repeatable read級別中，沒有臟讀現(xiàn)象。
接著，我們順著剛才的新插入的數(shù)據(jù)，然后將B終端的事務(wù)進行提交，然后再回到A終端查詢數(shù)據(jù)，依然沒有查詢到B終端剛才插入的ID為6的數(shù)據(jù)，以此也就表明，目前Mysql 5.6以上的版本中，Repeatable read級別已經(jīng)不存在幻讀的問題，而之前的版本我并未做測試，后面有時間會在去查一下，mysql是在哪個版本開始解決了幻讀問題。
由于剛才B終端已經(jīng)提交了事務(wù)，所以為了實驗是否存在不可重復(fù)讀的現(xiàn)象，我們重新開啟B終端的事務(wù)，然后我們將ID為5的name修改為Joy：
update test_tx set name = "Joy" where id = 5;，同時B終端的事務(wù)commit;，然后我們回到A終端進行查詢，三次的查詢結(jié)果都是一致的。所以實驗表明，在Repeatable read級別中，不存在不可重復(fù)讀現(xiàn)象。
總結(jié)，在Repeatable read級別中，臟讀、不可重復(fù)讀、幻讀現(xiàn)象都沒有。在mysql中，該級別也是默認的事務(wù)隔離級別，我們?nèi)粘Ｔ陂_發(fā)中，也是主要使用該隔離級別。
Serializable
Serializable完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互會相互互斥，這樣可以更好的解決數(shù)據(jù)一致性的問題，但是同樣會大大的降低數(shù)據(jù)庫的實際吞吐性能。所以該隔離級別因為損耗太大，一般很少在開發(fā)中使用。
總結(jié)：
| 隔離級別| 臟讀| 不可重復(fù)讀| 幻讀|
| ------------- |:-------------:| -----:|
| 未提交讀（Read uncommitted）| 可能| 可能|可能|
| 已提交讀（Read committed）| 不可能| 可能|可能|
| 可重復(fù)讀（Repeatable read）| 不可能 | 不可能 |不可能 |
| 可串行化（Serializable ）| 不可能 | 不可能 |不可能 |
