鍍金池/ 問答/數(shù)據(jù)庫/ 怎么理解SQL的四個事務(wù)隔離級別?

怎么理解SQL的四個事務(wù)隔離級別?

最近在讀PostgreSQL的官方文檔,PostgreSQL支持SQL標(biāo)準(zhǔn)定義的讀未提交、讀已提交、可重復(fù)讀、可串行化這4個事務(wù)隔離級別。而內(nèi)部其實只有讀已提交,可重復(fù)讀和可串行化這3種獨立的隔離級別,所以文檔里只說明了這3種隔離級別。問題是文檔里的說明比較生硬,看完似懂非懂。有沒有哪位大神幫我通俗的解釋一下這4個事務(wù)隔離級別?。?br>圖片描述

回答
編輯回答
爛人

我正在寫相關(guān)的一系列文章 有空的話你可以去看一下是否有幫助

2017年9月2日 17:52
編輯回答
練命

我認為要理解事務(wù)隔離級別,就必須先理解"臟讀","不可重復(fù)讀"和"幻讀"這三個現(xiàn)象。因此我會以下表為例直觀說明這三種讀的具體現(xiàn)象。

圖片描述

  • 臟讀

圖片描述

這種現(xiàn)象出現(xiàn)在事物間的隔離級別最差的場景下,寫事務(wù)對一個元組的更新尚未提交時就被另一個事務(wù)讀到了。如果在一個業(yè)務(wù)應(yīng)用中,寫事務(wù)后面沒提交而是回滾了,那么可以預(yù)見這個讀事務(wù)讀到的這個未提交的更新在某些業(yè)務(wù)場景下可能會帶來一些困擾。

  • 不可重復(fù)讀

圖片描述

這種現(xiàn)象比上面的臟讀好一點,只有當(dāng)寫事務(wù)提交后,這個更新才會被讀事務(wù)讀取到。但是考慮到如上圖所示,在同一個事務(wù)中的不同時間點意圖讀取同一個元組卻讀到了不同的數(shù)據(jù),在某些業(yè)務(wù)場景下可能也會帶來一些困擾。

劃重點: "臟讀"和"不可重復(fù)讀"這兩個現(xiàn)象針對的是對于表中的同一個邏輯上的元組而言.引發(fā)"臟讀"和"不可重復(fù)讀"這兩個現(xiàn)象的寫事務(wù)的操作通常是UPDATE
  • 幻讀

幻讀這一現(xiàn)象針對的已不是表中的單一元組而言,而是指讀事務(wù)在對表中的某個范圍多個元組而言的一種現(xiàn)象,引發(fā)幻讀的寫事務(wù)對應(yīng)的操作通常是INSERTDELETE。如下圖所示:

圖片描述

在同一個讀事務(wù)中,對于同一個過濾條件查詢出了不同的結(jié)果集,這在某些業(yè)務(wù)場景下也有可能帶來一定的困擾。

上面這些就是關(guān)于"臟讀","不可重復(fù)讀"以及"幻讀"這三個現(xiàn)象的介紹。除此之外,這邊還需要再強調(diào)兩個注意點:

  1. "臟讀","不可重復(fù)讀"以及"幻讀"這三個現(xiàn)象不是錯誤,更不是BUG。它們僅僅是事務(wù)并發(fā)場景下可能出現(xiàn)的現(xiàn)象。
  2. "臟讀","不可重復(fù)讀"以及"幻讀"針對的是同一個事務(wù)中的讀操作而言。為什么要強調(diào)這一點,因為有些對數(shù)據(jù)庫理解不深的同學(xué)不能很好的理解清楚 會話,事務(wù)語句這三個概念。于是對于以下的例子就會誤認為是"不可重復(fù)讀"的現(xiàn)象:

    圖片描述

    但事實上,它并非"不可重復(fù)讀"的例子。因為在會話2中沒有開啟顯式事務(wù),因此兩個SELECT語句分屬于不同事務(wù)。"臟讀","不可重復(fù)讀"以及"幻讀"的概念不適用于不同的事務(wù)之間的讀操作。


理解清楚了以上的這三個"讀"的概念后,就可以很容易的理解事務(wù)隔離級別了。因為事務(wù)隔離級別的設(shè)置本質(zhì)上就意味著讓你控制并發(fā)事務(wù)之間的寫事務(wù)帶來的數(shù)據(jù)更新的可見性——即,你允許業(yè)務(wù)中的并發(fā)事務(wù)之間出現(xiàn)怎樣的都現(xiàn)象. 由于"臟讀","不可重復(fù)讀"以及"幻讀"的概念是一種層層遞進的概念,因此事務(wù)隔離級別從"Read Uncommited"到"Serializable"也是一個比一個嚴格。

隔離級別 臟讀 不可重復(fù)讀 幻讀
READ UNCOMMITTED 允許 可能 可能
READ COMMITTED 不允許 可能 可能
REPEATABLE READ 不允許 不允許 可能
SERIALIZABLE 不允許 不允許 不允許

需要注意的是,SQL標(biāo)準(zhǔn)中對于這些隔離級別定義中約束的"不允許"現(xiàn)象是強制要求的。數(shù)據(jù)庫廠商在宣稱支持某個隔離級別時,必須將上表中對應(yīng)隔離級別的"不允許"進行實現(xiàn)。但是對于"可能"項則不代表你必須實現(xiàn)成具備某種都現(xiàn)象。在PostgreSQL中,由于其MVCC的實現(xiàn),REPEATABLE READ對于讀事務(wù)的行為實現(xiàn)也和SERIALIZABLE一樣是不會出現(xiàn)幻讀的,而REPEATABLE READSERIALIZABLE的區(qū)別,主要體現(xiàn)在下文所述的對更新操作的約束力度上。

此外,需要特別說明一下SERIALIZABLE這個隔離級別對于并發(fā)寫事務(wù)有所約束:

在其他隔離級別中,如果并發(fā)的兩個事務(wù)同時意圖對同一個元組進行更新時, 后更新的事務(wù)會等待直到先更新的事務(wù)提交后在繼續(xù)執(zhí)行其更新操作。 但是在SERIALIZABLE的情況下,由于此時事務(wù)隔離級別最強,會對有可能對讀一致性帶來影響的寫操作必須按照事務(wù)的串行執(zhí)行。在PG的實現(xiàn)中,這表現(xiàn)為嘗試對于同一元組進行更新的并發(fā)事務(wù)會在等待完先更新的事務(wù)提交后自己報個錯:

圖片描述

SERIALIZABLE隔離級別下,對于上圖中的兩個更新事務(wù)若都希望成功,需要保證右邊會話的更新操作所屬事務(wù)的START TRANSACTION必須發(fā)生在左邊會話的更新事務(wù)COMMIT之后。

以上,就是關(guān)于事務(wù)隔離級別的那點兒事,希望我這個回答能夠幫題主解惑。

2018年8月23日 14:13
編輯回答
故人嘆

讀未提交:事務(wù)T在修改數(shù)據(jù)R之前必須先對其加排它鎖,事務(wù)結(jié)束后釋放
讀已提交:一級封鎖協(xié)議+事務(wù)T在讀取數(shù)據(jù)R之前必須先對其加共享鎖,讀取后(事務(wù)結(jié)束前)釋放
可重復(fù)讀:一級封鎖協(xié)議+事務(wù)T在讀取數(shù)據(jù)R之前必須先對其加共享鎖,事務(wù)結(jié)束后釋放

2017年8月11日 01:36