什么是事務隔離?

任何支持事務的數(shù)據(jù)庫，都必須具備四個特性，分別是：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)，也就是我們常說的事務ACID，這樣才能保證事務((Transaction)中數(shù)據(jù)的正確性。 

而事務的隔離性就是指，多個并發(fā)的事務同時訪問一個數(shù)據(jù)庫時，一個事務不應該被另一個事務所干擾，每個并發(fā)的事務間要相互進行隔離。

如果沒有事務隔離，會出現(xiàn)什么樣的情況呢?

假設我們現(xiàn)在有這樣一張表(T)，里面記錄了很多牛人的名字，我們不進行事務的隔離看看會發(fā)生什么呢? 

***天，事務A訪問了數(shù)據(jù)庫，它干了一件事情，往數(shù)據(jù)庫里加上了新來的牛人的名字，但是沒有提交事務。 

insert into T values (4, '牛D'); 

這時，來了另一個事務B，他要查詢所有牛人的名字。 

select Name from T; 

這時，如果沒有事務之間沒有有效隔離，那么事務B返回的結果中就會出現(xiàn)“牛D”的名字。這就是“臟讀(dirty read)”。

第二天，事務A訪問了數(shù)據(jù)庫，他要查看ID是1的牛人的名字，于是執(zhí)行了 

select Name from T where ID = 1; 

這時，事務B來了，因為ID是1的牛人改名字了，所以要更新一下，然后提交了事務。 

update T set Name = '不牛' where ID = 1; 

接著，事務A還想再看看ID是1的牛人的名字，于是又執(zhí)行了 

select Name from T where ID = 1; 

結果，兩次讀出來的ID是1的牛人名字竟然不相同，這就是不可重復讀(unrepeatable read)。 

第三天，事務A訪問了數(shù)據(jù)庫，他想要看看數(shù)據(jù)庫的牛人都有哪些，于是執(zhí)行了 

select * from T; 

這時候，事務B來了，往數(shù)據(jù)庫加入了一個新的牛人。 

insert into T values(4, '牛D'); 

這時候，事務A忘了剛才的牛人都有哪些了，于是又執(zhí)行了。 

select * from T; 

結果，***次有三個牛人，第二次有四個牛人。

相信這個時候事務A就蒙了，剛才發(fā)生了什么?這種情況就叫“幻讀(phantom problem)”。 

為了防止出現(xiàn)臟讀、不可重復讀、幻讀等情況，我們就需要根據(jù)我們的實際需求來設置數(shù)據(jù)庫的隔離級別。

數(shù)據(jù)庫都有哪些隔離級別呢?

一般的數(shù)據(jù)庫，都包括以下四種隔離級別：

1. 讀未提交(Read Uncommitted)
2. 讀提交(Read Committed)
3. 可重復讀(Repeated Read)
4. 串行化(Serializable)

如何使用這些隔離級別，那就需要根據(jù)業(yè)務的實際情況來進行判斷了。

我們接下來就看看這四個隔離級別的具體情況

讀未提交(Read Uncommitted)

讀未提交，顧名思義，就是可以讀到未提交的內(nèi)容。

因此，在這種隔離級別下，查詢是不會加鎖的，也由于查詢的不加鎖，所以這種隔離級別的一致性是最差的，可能會產(chǎn)生“臟讀”、“不可重復讀”、“幻讀”。

如無特殊情況，基本是不會使用這種隔離級別的。

讀提交(Read Committed)

讀提交，顧名思義，就是只能讀到已經(jīng)提交了的內(nèi)容。

這是各種系統(tǒng)中最常用的一種隔離級別，也是SQL Server和Oracle的默認隔離級別。這種隔離級別能夠有效的避免臟讀，但除非在查詢中顯示的加鎖，如： 

select * from T where ID=2 lock in share mode;  
select * from T where ID=2 for update;  

不然，普通的查詢是不會加鎖的。

那為什么“讀提交”同“讀未提交”一樣，都沒有查詢加鎖，但是卻能夠避免臟讀呢?

這就要說道另一個機制“快照(snapshot)”，而這種既能保證一致性又不加鎖的讀也被稱為“快照讀(Snapshot Read)” 

假設沒有“快照讀”，那么當一個更新的事務沒有提交時，另一個對更新數(shù)據(jù)進行查詢的事務會因為無法查詢而被阻塞，這種情況下，并發(fā)能力就相當?shù)牟睢?/p>

而“快照讀”就可以完成高并發(fā)的查詢，不過，“讀提交”只能避免“臟讀”，并不能避免“不可重復讀”和“幻讀”。

可重復讀(Repeated Read)

可重復讀，顧名思義，就是專門針對“不可重復讀”這種情況而制定的隔離級別，自然，它就可以有效的避免“不可重復讀”。而它也是MySql的默認隔離級別。

在這個級別下，普通的查詢同樣是使用的“快照讀”，但是，和“讀提交”不同的是，當事務啟動時，就不允許進行“修改操作(Update)”了，而“不可重復讀”恰恰是因為兩次讀取之間進行了數(shù)據(jù)的修改，因此，“可重復讀”能夠有效的避免“不可重復讀”，但卻避免不了“幻讀”，因為幻讀是由于“插入或者刪除操作(Insert or Delete)”而產(chǎn)生的。

串行化(Serializable)

這是數(shù)據(jù)庫***的隔離級別，這種級別下，事務“串行化順序執(zhí)行”，也就是一個一個排隊執(zhí)行。

這種級別下，“臟讀”、“不可重復讀”、“幻讀”都可以被避免，但是執(zhí)行效率奇差，性能開銷也***，所以基本沒人會用。

總結一下

為什么會出現(xiàn)“臟讀”?因為沒有“select”操作沒有規(guī)矩。

為什么會出現(xiàn)“不可重復讀”?因為“update”操作沒有規(guī)矩。

為什么會出現(xiàn)“幻讀”?因為“insert”和“delete”操作沒有規(guī)矩。

“讀未提(Read Uncommitted)”能預防啥?啥都預防不了。

“讀提交(Read Committed)”能預防啥?使用“快照讀(Snapshot Read)”，避免“臟讀”，但是可能出現(xiàn)“不可重復讀”和“幻讀”。

“可重復讀(Repeated Red)”能預防啥?使用“快照讀(Snapshot Read)”，鎖住被讀取記錄，避免出現(xiàn)“臟讀”、“不可重復讀”，但是可能出現(xiàn)“幻讀”。

“串行化(Serializable)”能預防啥?排排坐，吃果果，有效避免“臟讀”、“不可重復讀”、“幻讀”，不過效果誰用誰知道。