好久沒碰數(shù)據(jù)庫了，只是想起自己當時在搞數(shù)據(jù)庫的時候在事務隔離級別這塊老是卡，似懂非懂的。現(xiàn)在想把這塊整理出來，盡量用最簡潔的語言描述出來，供新人參考。

首先創(chuàng)建一個表account。創(chuàng)建表的過程略過（由于InnoDB存儲引擎支持事務，所以將表的存儲引擎設置為InnoDB）。表的結構如下：

表結構

然后往表中插入兩條數(shù)據(jù)，插入后結果如下：

數(shù)據(jù)

為了說明問題，我們打開兩個控制臺分別進行登錄來模擬兩個用戶（暫且成為用戶A和用戶B吧），并設置當前MySQL會話的事務隔離級別。

一. read uncommitted（讀取未提交數(shù)據(jù)）

具體用戶A的操作如下：

set session transaction isolation level read uncommitted； start transaction; select * from account;

結果如下：

數(shù)據(jù)

用戶B的操作如下：

set session transaction isolation level read uncommitted； start transaction; update account set account=account+200 where id = 1;

隨后我們在A用戶中查詢數(shù)據(jù)，結果如下：

uncommittedA數(shù)據(jù)

結論一：

我們將事務隔離級別設置為read uncommitted，即便是事務沒有commit，但是我們仍然能讀到未提交的數(shù)據(jù)，這是所有隔離級別中最低的一種。

那么這么做有什么問題嗎？

那就是我們在一個事務中可以隨隨便便讀取到其他事務未提交的數(shù)據(jù)，這還是比較麻煩的，我們叫臟讀。我不知道這個名字是怎么起的，為了增強大家的印象，可以這么想，這個事務好輕浮啊，饑渴到連別人沒提交的東西都等不及，真臟，呸！

實際上我們的數(shù)據(jù)改變了嗎？

答案是否定的，因為只有事務commit后才會更新到數(shù)據(jù)庫。

二. read committed（可以讀取其他事務提交的數(shù)據(jù)）---大多數(shù)數(shù)據(jù)庫默認的隔離級別

同樣的辦法，我們將用戶B所在的會話當前事務隔離級別設置為read commited。

在用戶A所在的會話中我們執(zhí)行下面操作：

update account set account=account-200 where id=1;

read committed

我們將id=1的用戶account減200。然后查詢，發(fā)現(xiàn)id=1的用戶account變?yōu)?00。

在B用戶所在的會話中查詢：

select * from account；

結果如下：

read committedB

我們會發(fā)現(xiàn)數(shù)據(jù)并沒有變，還是1000。

接著在會話A中我們將事務提交：

commit;

在會話B中查詢結果如下：

read committedB1

結論二：

當我們將當前會話的隔離級別設置為read committed的時候，當前會話只能讀取到其他事務提交的數(shù)據(jù)，未提交的數(shù)據(jù)讀不到。

那么這么做有什么問題嗎？

那就是我們在會話B同一個事務中，讀取到兩次不同的結果。這就造成了不可重復讀，就是兩次讀取的結果不同。這種現(xiàn)象叫不可重復讀。

三. repeatable read（可重讀）---MySQL默認的隔離級別

現(xiàn)在有個需求，就是老板說在同一個事務中查詢結果必須保持一致，如果你是數(shù)據(jù)庫，你會怎么做？數(shù)據(jù)庫是這么做的。

在會話B中我們當前事務隔離級別為repeatable read。具體操作如下：

set session transaction isolation level repeatable read; start transaction;

接著在會話B中查詢數(shù)據(jù)：

repeatablereadB1

我們在A用戶所在會話中為表account添加一條數(shù)據(jù)：

insert into account(id,account) value(3,1000); commit;

然后我們查詢看數(shù)據(jù)插入是否成功：

repeatable readA

回到B用戶所在的會話，我們查詢結果：

repeatablereadB2

用戶B在他所在的會話中想插入一條新數(shù)據(jù)id=3，value=1000。來我們操作下：

readpeatablereadB3

什么？竟然插不進去，說我數(shù)據(jù)重復？

用戶B當然不服啊，因為查詢到數(shù)據(jù)只有兩條啊，為什么插入id=3說我數(shù)據(jù)重復了呢？

我再看一遍，莫非我眼花了？

repeatablereadB2

試想一下，在實際中用戶A和用戶B肯定是相互隔離的，彼此不知道操作什么。用戶B碰到這種現(xiàn)象，肯定會炸毛的啊，明明不存在的數(shù)據(jù)，插入?yún)s說主鍵id=3數(shù)據(jù)重復了。

結論三：

當我們將當前會話的隔離級別設置為repeatable read的時候，當前會話可以重復讀，就是每次讀取的結果集都相同，而不管其他事務有沒有提交。

有什么問題嗎？

管他呢，老板的要求滿足了。要一個事務中讀取的數(shù)據(jù)一致（可重復讀）。我只能這么做啊，打腫臉裝胖子。數(shù)據(jù)已經發(fā)生改變，但是我還是要保持一致。但是，出現(xiàn)了用戶B面對的問題，這種現(xiàn)象叫幻讀（記得當時就在這個地方糾結好久，到底什么是幻讀啊）。

四. serializable（串行化）

同樣，我們將用戶B所在的會話的事務隔離級別設置為serializable并開啟事務。

set session transaction isolation level serializable; start transaction;

在用戶B所在的會話中我們執(zhí)行下面操作：

select * from account;

結果如下：

serializableA

那我們這個時候在用戶A所在的會話中寫數(shù)據(jù)呢？

?

readcommittedA1

我們發(fā)現(xiàn)用戶A所在的會話陷入等待，如果超時（這個時間可以進行配置），會出現(xiàn)Lock wait time out提示：

readcommittedA2

如果在等待期間我們用戶B所在的會話事務提交，那么用戶A所在的事務的寫操作將提示操作成功。

結論四：

當我們將當前會話的隔離級別設置為serializable的時候，其他會話對該表的寫操作將被掛起。可以看到，這是隔離級別中最嚴格的，但是這樣做勢必對性能造成影響。所以在實際的選用上，我們要根據(jù)當前具體的情況選用合適的。

作者：傘U
鏈接：https://www.jianshu.com/p/4e3edbedb9a8
來源：簡書
?

?

總結

以上是生活随笔為你收集整理的五分钟搞清楚MySQL事务隔离级别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。