從新學習Mysql數據庫8：MySQL的事務隔離級別實戰

在Mysql中，事務主要有四種隔離級別，今天咱們主要是經過示例來比較下，四種隔離級別實際在應用中，會出現什麼樣的對應現象。

1. Read uncommitted (未提交讀)
2. Read committed (已提交讀)
3. Repeatable read (可重複讀)
4. Serializable (可串行化)

在理解四種隔離級別以前，咱們須要先了解另外三個名詞：

1. 髒讀
2. 不可重複讀
3. 幻讀

髒讀

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」 等關鍵字能夠獲取對應的免費學習資料。