首先創建一個表account。創建表的過程略過。表的結構如下:
然後往表中插入兩條數據,插入後結果如下:
定義兩個事務:A用戶 和 B用戶。
一. read uncommitted(可以讀取未提交數據)
set session transaction isolation level read uncommitted;
start transaction;
select * from account;
B執行如下操作:
set session transaction isolation level read uncommitted;
start transaction;
update account set account=account+200 where id = 1;
最後A用戶查詢結果:
結論:
我們將事務隔離級別設置爲read uncommitted,即便是事務沒有commit,但是我們仍然能讀到未提交的數據,這是所有隔離級別中最低的一種。
那麼這麼做存在什麼問題呢?
那就是我們在一個事務中可以隨隨便便讀取到其他事務未提交的數據,這還是比較麻煩的,我們叫髒讀。我不知道這個名字是怎麼起的,爲了增強大家的印象,可以這麼想,這個事務好輕浮啊,飢渴到連別人沒提交的東西都等不及,真髒,呸!
實際上我們的數據改變了嗎?
答案是否定的,因爲只有事務commit後纔會更新到數據庫。
二. read committed(可以讀取其他事務提交的數據)---大多數數據庫默認的隔離級別
同樣的辦法,我們將用戶B所在的會話當前事務隔離級別設置爲read commited。
在用戶A所在的會話中我們執行下面操作:
update account set account=account-200 where id=1;
我們將id=1的用戶account減200。然後查詢,發現id=1的用戶account變爲800。
在B用戶所在的會話中查詢:
select * from account;
我們會發現數據並沒有變,還是1000。
接着在會話A中我們將事務提交:
commit;
在會話B中查詢結果如下:結論二:
當我們將當前會話的隔離級別設置爲read committed的時候,當前會話只能讀取到其他事務提交的數據,未提交的數據讀不到。
那麼這麼做有什麼問題嗎?
那就是我們在會話B同一個事務中,讀取到兩次不同的結果。這就造成了不可重複讀,就是兩次讀取的結果不同。這種現象叫不可重複讀。
三. repeatable read(可重讀)---MySQL默認的隔離級別
現在有個需求,就是老闆說在同一個事務中查詢結果必須保持一致,如果你是數據庫,你會怎麼做?數據庫是這麼做的。
在會話B中我們當前事務隔離級別爲repeatable read。具體操作如下:
set session transaction isolation level repeatable read;
start transaction;
接着在會話B中查詢數據:insert into account(id,account) value(3,1000);
commit;
然後我們查詢看數據插入是否成功:什麼?竟然插不進去,說我數據重複?
用戶B當然不服啊,因爲查詢到數據只有兩條啊,爲什麼插入id=3說我數據重複了呢?
我再看一遍,莫非我眼花了?
試想一下,在實際中用戶A和用戶B肯定是相互隔離的,彼此不知道操作什麼。用戶B碰到這種現象,肯定會炸毛的啊,明明不存在的數據,插入卻說主鍵id=3數據重複了。
結論三:
當我們將當前會話的隔離級別設置爲repeatable read的時候,當前會話可以重複讀,就是每次讀取的結果集都相同,而不管其他事務有沒有提交。
有什麼問題嗎?
管他呢,老闆的要求滿足了。要一個事務中讀取的數據一致(可重複讀)。我只能這麼做啊,打腫臉裝胖子。數據已經發生改變,但是我還是要保持一致。但是,出現了用戶B面對的問題,這種現象叫幻讀(記得當時就在這個地方糾結好久,到底什麼是幻讀啊)。
四. serializable(串行化)
同樣,我們將用戶B所在的會話的事務隔離級別設置爲serializable並開啓事務。
set session transaction isolation level serializable;
start transaction;
結果如下:讀沒有問題,那我們在用戶A所在的會話中寫數據呢?
如果在等待期間我們用戶B所在的會話事務提交,那麼用戶A所在的事務的寫操作將提示操作成功。
結論四:
當我們將當前會話的隔離級別設置爲serializable的時候,其他會話對該表的寫操作將被掛起。可以看到,這是隔離級別中最嚴格的,但是這樣做勢必對性能造成影響。所以在實際的選用上,我們要根據當前具體的情況選用合適的。
原文鏈接:http://www.jianshu.com/p/4e3edbedb9a8