很多小伙伴對 mysql 的隔離級別一直心存疑惑，其實這個問題一點都不難，關鍵看怎么講！單純的看理論，絕對讓你暈頭轉向，但是，如果我們通過幾個實際的 sql 來演示一些，大家就會發現這玩意原來這么簡單！
今天松哥想通過幾個簡單的案例，來和大家演示一下 mysql 中的事務隔離級別問題。
1. 理論
mysql 中事務的隔離級別一共分為四種，分別如下：
- 序列化（serializable）
- 可重復讀（repeatable read）
- 提交讀（read committed）
- 未提交讀（read uncommitted）
四種不同的隔離級別含義分別如下：
serializable
如果隔離級別為序列化，則用戶之間通過一個接一個順序地執行當前的事務，這種隔離級別提供了事務之間最大限度的隔離。
repeatable read
在可重復讀在這一隔離級別上，事務不會被看成是一個序列。不過，當前正在執行事務的變化仍然不能被外部看到，也就是說，如果用戶在另外一個事務中執行同條 select 語句數次，結果總是相同的。（因為正在執行的事務所產生的數據變化不能被外部看到）。
read committed
read committed 隔離級別的安全性比 repeatable read 隔離級別的安全性要差。處于 read committed 級別的事務可以看到其他事務對數據的修改。也就是說，在事務處理期間，如果其他事務修改了相應的表，那么同一個事務的多個 select 語句可能返回不同的結果。
read uncommitted
read uncommitted 提供了事務之間最小限度的隔離。除了容易產生虛幻的讀操作和不能重復的讀操作外，處于這個隔離級的事務可以讀到其他事務還沒有提交的數據，如果這個事務使用其他事務不提交的變化作為計算的基礎，然后那些未提交的變化被它們的父事務撤銷，這就導致了大量的數據變化。
在 mysql 數據庫種，默認的事務隔離級別是 repeatable read
2. sql 實踐
接下來通過幾條簡單的 sql 向讀者驗證上面的理論。
2.1 查看隔離級別
通過如下 sql 可以查看數據庫實例默認的全局隔離級別和當前 session 的隔離級別：
mysql8 之前使用如下命令查看 mysql 隔離級別：
|
1
|
select @@global.tx_isolation, @@tx_isolation; |
查詢結果如圖：
可以看到，默認的隔離級別為 repeatable-read，全局隔離級別和當前會話隔離級別皆是如此。
mysql8 開始，通過如下命令查看 mysql 默認隔離級別：
|
1
|
select @@global.transaction_isolation, @@transaction_isolation; |
就是關鍵字變了，其他都一樣。
通過如下命令可以修改隔離級別（建議開發者在修改時修改當前 session 隔離級別即可，不用修改全局的隔離級別）：
|
1
|
set session transaction isolation level read uncommitted |
上面這條 sql 表示將當前 session 的數據庫隔離級別設置為 read uncommitted，設置成功后，再次查詢隔離級別，發現當前 session 的隔離級別已經變了，如圖1-2：
注意，如果只是修改了當前 session 的隔離級別，則換一個 session 之后，隔離級別又會恢復到默認的隔離級別，所以我們測試時，修改當前 session 的隔離級別即可。
2.2 read uncommitted
2.2.1 準備測試數據
read uncommitted 是最低隔離級別，這種隔離級別中存在臟讀、不可重復讀以及幻象讀問題，所以這里我們先來看這個隔離級別，借此大家可以搞懂這三個問題到底是怎么回事。
下面分別予以介紹。
首先創建一個簡單的表，預設兩條數據，如下：
表的數據很簡單，有 javaboy 和 itboyhub 兩個用戶，兩個人的賬戶各有 1000 人民幣。現在模擬這兩個用戶之間的一個轉賬操作。
注意，如果讀者使用的是 navicat 的話，不同的查詢窗口就對應了不同的 session，如果讀者使用了 sqlyog 的話，不同查詢窗口對應同一個 session，因此如果使用 sqlyog，需要讀者再開啟一個新的連接，在新的連接中進行查詢操作。
2.2.2 臟讀
一個事務讀到另外一個事務還沒有提交的數據，稱之為臟讀。具體操作如下：
首先打開兩個sql操作窗口，假設分別為 a 和 b，在 a 窗口中輸入如下幾條 sql （輸入完成后不用執行）：
|
1
2
3
4
|
start transaction;update account set balance=balance+100 where name='javaboy';update account set balance=balance-100 where name='itboyhub';commit; |
在 b 窗口執行如下 sql，修改默認的事務隔離級別為 read uncommitted，如下：
|
1
|
set session transaction isolation level read uncommitted |
接下來在 b 窗口中輸入如下 sql，輸入完成后，首先執行第一行開啟事務（注意只需要執行一行即可）：
|
1
2
3
|
start transaction;select * from account;commit; |
接下來執行 a 窗口中的前兩條 sql，即開啟事務，給 javaboy 這個賬戶添加 100 元。
進入到 b 窗口，執行 b 窗口的第二條查詢 sql（select * from user;），結果如下：
可以看到，a 窗口中的事務，雖然還未提交，但是 b 窗口中已經可以查詢到數據的相關變化了。
這就是臟讀問題。
2.2.3 不可重復讀
不可重復讀是指一個事務先后讀取同一條記錄，但兩次讀取的數據不同，稱之為不可重復讀。具體操作步驟如下（操作之前先將兩個賬戶的錢都恢復為1000）：
- 首先打開兩個查詢窗口 a 和 b ，并且將 b 的數據庫事務隔離級別設置為 read uncommitted。具體 sql 參考上文，這里不贅述。
- 在 b 窗口中輸入如下 sql，然后只執行前兩條 sql 開啟事務并查詢 javaboy 的賬戶：
|
1
2
3
|
start transaction;select * from account where name='javaboy';commit; |
前兩條 sql 執行結果如下：
在 a 窗口中執行如下 sql，給 javaboy 這個賬戶添加 100 塊錢，如下：
|
1
2
3
|
start transaction;update account set balance=balance+100 where name='javaboy';commit; |
4.再次回到 b 窗口，執行 b 窗口的第二條 sql 查看 javaboy 的賬戶，結果如下：
javaboy 的賬戶已經發生了變化，即前后兩次查看 javaboy 賬戶，結果不一致，這就是不可重復讀。
和臟讀的區別在于，臟讀是看到了其他事務未提交的數據，而不可重復讀是看到了其他事務已經提交的數據（由于當前 sql 也是在事務中，因此有可能并不想看到其他事務已經提交的數據）。
2.2.4 幻象讀
幻象讀和不可重復讀非常像，看名字就是產生幻覺了。
我舉一個簡單例子。
在 a 窗口中輸入如下 sql：
|
1
2
3
|
start transaction;insert into account(name,balance) values('zhangsan',1000);commit; |
然后在 b 窗口輸入如下 sql：
|
1
2
3
4
|
start transaction;select * from account;delete from account where name='zhangsan';commit; |
我們執行步驟如下：
- 首先執行 b 窗口的前兩行，開啟一個事務，同時查詢數據庫中的數據，此時查詢到的數據只有 javaboy 和 itboyhub。
- 執行 a 窗口的前兩行，向數據庫中添加一個名為 zhangsan 的用戶，注意不用提交事務。
- 執行 b 窗口的第二行，由于臟讀問題，此時可以查詢到 zhangsan 這個用戶。
- 執行 b 窗口的第三行，去刪除 name 為 zhangsan 的記錄，這個時候刪除就會出問題，雖然在 b 窗口中可以查詢到 zhangsan，但是這條記錄還沒有提交，是因為臟讀的原因才看到了，所以是沒法刪除的。此時就產生了幻覺，明明有個 zhangsan，卻無法刪除。
這就是幻讀。
看了上面的案例，大家應該明白了臟讀、不可重復讀以及幻讀各自是什么含義了。
2.3 read committed
和 read uncommitted 相比，read committed 主要解決了臟讀的問題，對于不可重復讀和幻象讀則未解決。
將事務的隔離級別改為 read committed 之后，重復上面關于臟讀案例的測試，發現已經不存在臟讀問題了；重復上面關于不可重復讀案例的測試，發現不可重復讀問題依然存在。
上面那個案例不適用于幻讀的測試，我們換一個幻讀的測試案例。
還是兩個窗口 a 和 b，將 b 窗口的隔離級別改為 read committed，
然后在 a 窗口輸入如下測試 sql：
|
1
2
3
|
start transaction;insert into account(name,balance) values('zhangsan',1000);commit; |
在 b 窗口輸入如下測試 sql：
|
1
2
3
4
|
start transaction;select * from account;insert into account(name,balance) values('zhangsan',1000);commit; |
測試方式如下：
- 首先執行 b 窗口的前兩行 sql，開啟事務并查詢數據，此時查到的只有 javaboy 和 itboyhub 兩個用戶。
- 執行 a 窗口的前兩行 sql，插入一條記錄，但是并不提交事務。
- 執行 b 窗口的第二行 sql，由于現在已經沒有了臟讀問題，所以此時查不到 a 窗口中添加的數據。
- 執行 b 窗口的第三行 sql，由于 name 字段唯一，因此這里會無法插入。此時就產生幻覺了，明明沒有 zhangsan 這個用戶，卻無法插入 zhangsan。
2.4 repeatable read
和 read committed 相比，repeatable read 進一步解決了不可重復讀的問題，但是幻象讀則未解決。
repeatable read 中關于幻讀的測試和上一小節基本一致，不同的是第二步中執行完插入 sql 后記得提交事務。
由于 repeatable read 已經解決了不可重復讀，因此第二步即使提交了事務，第三步也查不到已經提交的數據，第四步繼續插入就會出錯。
注意，repeatable read 也是 innodb 引擎的默認數據庫事務隔離級別
2.5 serializable
serializable 提供了事務之間最大限度的隔離，在這種隔離級別中，事務一個接一個順序的執行，不會發生臟讀、不可重復讀以及幻象讀問題，最安全。
如果設置當前事務隔離級別為 serializable，那么此時開啟其他事務時，就會阻塞，必須等當前事務提交了，其他事務才能開啟成功，因此前面的臟讀、不可重復讀以及幻象讀問題這里都不會發生。
3. 總結
總的來說，隔離級別和臟讀、不可重復讀以及幻象讀的對應關系如下：
| 隔離級別 | 臟讀 | 不可重復讀 | 幻象讀 |
|---|---|---|---|
| read uncommitted | 允許 | 允許 | 允許 |
| read commited | 不允許 | 允許 | 允許 |
| repeatable read | 不允許 | 不允許 | 允許 |
| serializable | 不允許 | 不允許 | 不允許 |
性能關系如圖：
好了，這篇文章就和小伙伴們先說這么多，大家不妨寫幾行 sql 試一試。
到此這篇關于mysql案例刨析事務隔離級別的文章就介紹到這了,更多相關mysql 事務隔離級別內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！
原文鏈接：https://blog.csdn.net/u012702547/article/details/120000704
