在Mysql中，事務主要有四種隔離級別，今天我們主要是通過示例來比較下，四種隔離級別實際在應用中，會出現什么樣的對應現象。
- Read uncommitted (未提交讀)
- Read committed (已提交讀)
- Repeatable read (可重復讀)
- Serializable (可串行化)
在理解四種隔離級別之前，我們需要先了解另外三個名詞：
- 臟讀
- 不可重復讀
- 幻讀
臟讀
A事務，會讀取到B事務還未提交的數據。因為B事務可能會因為各種原因數據回滾，所以如果A事務讀取了B未提交的數據，然后基于此進行一些業務操作，但是B事務發生錯誤回滾了，那A事務的業務操作就錯了。
不可重復讀
在同一個事務生命周期內，也就是這個事務還未提交之前。如果另外一個事務，對數據進行了編輯(update)或者刪除(delete)操作。那么A事務就會讀取到。簡單理解，就是在一個事務生命周期內，多次查詢數據，每次都可能查出來的不一樣。
幻讀
幻讀的結果其實和不可重復讀是一樣的表現，差異就在于，不可重復讀，主要是針對其他事務進行了編輯(update)和刪除(delete)操作。而幻讀主要是針對插入(insert)操作。也就是在一個事務生命周期內，會查詢到另外一個事務新插入的數據。
下面我們就直接來通過實驗來看，Mysql Innodb中，不同的事務隔離級別，會出現怎么樣的結果。
首先我們開啟兩個終端，查詢當前MySQL的默認隔離級別:
<pre>SELECT @@global.tx_isolation; //查詢全局事務SELECT @@session.tx_isolation; //查詢當前會話事務
</pre>
可以看到，默認的隔離級別是：REPEATABLE-READ
1.實驗Read uncommitted
我們將會話事務設置為：Read uncommitted
<pre>SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
//測試可以不用設置全局事務SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;(這個可以不用設，只設置上面一行就可以了進行測試了)
</pre>
更改完之后，重新查詢事務：
可以看到，全局事務已經更改為Read uncommitted
然后，我們首先創建一個測試的數據庫test_tx，并插入了2條測試數據，如下圖：
然后我們分別開啟事務，然后我們在B終端中，插入一條數據，但是不提交，然后在A終端進行數據查詢。
可以看到，我們在B終端insert一條數據，但是未進行提交操作(commit)，但是在A事務中，卻查詢到了。我們稱這種現象叫做臟讀，在實際開發過程中，我們一般較少使用Read uncommitted隔離級別，這種隔離級別對任何的數據操作都不會進行加鎖。
2.實驗Read committed
首先我們將會話的事務隔離級別設置為read committed
<pre>SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
</pre>
然后我們用上面相同的方式，進行測試。首先同時將2個終端的事務開啟：begin;，然后在B終端中插入一條新的數據insert into test_tx values(4,"Lee");，但是不提交事務(commit)，然后在A終端中，查詢數據，如圖，我們在A終端中，沒有查詢到剛才插入的這條數據。
所以，實驗表明，在Read committed隔離級別，不會出現臟讀的問題。
然后我們繼續做實驗，看看在Read committed隔離級別中，會不會出現不可重復讀、幻讀的現象。
我們同時打開兩個終端的事務，然后在A終端中，查詢當前的數據，然后我們在B終端中，將ID為3的數據，name修改為Jeff。然后將B終端的事務提交(commit)，但是A終端不提交事務，在一個事務的生命周期內，然后查詢數據，我們查詢到了剛才B終端修改過的數據。也就是說，我們在A終端的一個事務周期內(事務未commit)，兩次查詢，得到的結果是不一樣的。
實驗表明，在Read committed隔離級別中，存在不可重復讀的現象。
我們繼續做實驗，因為剛才B終端已經將事務提交，所以我們重新打開B終端的事務，然后我們在B終端中，插入(insert)一條ID為5的新數據，并提交事務。然后我們回到A終端，查詢數據，我們同樣可以查詢到剛才B終端新插入的數據。也就是說我們在A終端中，三次查詢，得到的結果都是不一樣的。
實驗表明，在Read committed隔離級別中，存在幻讀的現象。
總結，在Read committed隔離級別中，可以有效解決臟讀問題，但是有不可重復讀、幻讀問題，而不可重復讀和幻讀的差異主要是，不可重復讀主要是針對修改和刪除操作、幻讀針對插入數據操作。
3.實驗Repeatable read
首先我們將隔離級別更改為Repeatable read
<pre>SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
</pre>
然后我們首先實驗，在Repeatable read級別中是否存在臟讀問題，我們首先同時開啟A,B兩個終端的事務(begin;)，然后在B終端中，插入一條ID為6的數據，但是不提交事務。然后在A終端中進行數據查詢，結果是我們未查詢到剛才插入的數據，所以在Repeatable read級別中，沒有臟讀現象。
接著，我們順著剛才的新插入的數據，然后將B終端的事務進行提交，然后再回到A終端查詢數據，依然沒有查詢到B終端剛才插入的ID為6的數據，以此也就表明，目前Mysql 5.6以上的版本中，Repeatable read級別已經不存在幻讀的問題，而之前的版本我并未做測試，后面有時間會在去查一下，mysql是在哪個版本開始解決了幻讀問題。
由于剛才B終端已經提交了事務，所以為了實驗是否存在不可重復讀的現象，我們重新開啟B終端的事務，然后我們將ID為5的name修改為Joy：update test_tx set name = "Joy" where id = 5;，同時B終端的事務commit;，然后我們回到A終端進行查詢，三次的查詢結果都是一致的。所以實驗表明，在Repeatable read級別中，不存在不可重復讀現象。
總結，在Repeatable read級別中，臟讀、不可重復讀、幻讀現象都沒有。在mysql中，該級別也是默認的事務隔離級別，我們日常在開發中，也是主要使用該隔離級別。
4.Serializable
Serializable完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互會相互互斥，這樣可以更好的解決數據一致性的問題，但是同樣會大大的降低數據庫的實際吞吐性能。所以該隔離級別因為損耗太大，一般很少在開發中使用。
?聲明：除非注明，本站所有文章皆為原創，轉載請以鏈接形式標明本文地址。
?轉載請注明來源：https://www.rjkf.cn/spring-boot-shi-wu-ge-chi-ji-bie/
微信公眾號【黃小斜】大廠程序員，互聯網行業新知，終身學習踐行者。關注后回復「Java」、「Python」、「C++」、「大數據」、「機器學習」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「筆試」、「面試」、「面經」、「計算機基礎」、「LeetCode」 等關鍵字可以獲取對應的免費學習資料。
