事務的隔離級別

髒讀（Dirty Read)

    髒讀意味着一個事務讀取了另外一個事務未提交的數據,而這個數據是有可能回滾

 

 

不可重複讀(Unrepeatable Read)

 

     不可重複讀意味着，在數據庫訪問中，一個事務範圍內兩個相同的查詢卻返回了不一樣數據。這是因爲查詢時系統中其餘事務修改的提交而引發的。

    例如：事務B中對某個查詢執行兩次，當第一次執行完時，事務A對其數據進行了修改。事務B中再次查詢時，數據發生了改變

 

幻讀(phantom read)

 

幻讀,是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的所有數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麼，之後就會發生操做第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺同樣.

 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

數據庫事務的隔離級別有4個，由低到高依次爲Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別能夠逐個解決髒讀、不可重複讀、幻讀這幾類問題。

 

√: 可能出現    ×: 不會出現

	髒讀	不可重複讀	幻讀
Read uncommitted	√	√	√
Read committed	×	√	√
Repeatable read	×	×	√
Serializable	×	×	×

 

注意：咱們討論隔離級別的場景，主要是在多個事務併發的狀況下，所以，接下來的講解都圍繞事務併發。

Read uncommitted 讀未提交

公司發工資了，領導把5000元打到singo的帳號上，可是該事務並未提交，而singo正好去查看帳戶，發現工資已經到帳，是5000元整，很是高興。但是不幸的是，領導發現發給singo的工資金額不對，是2000元，因而迅速回滾了事務，修改金額後，將事務提交，最後singo實際的工資只有2000元，singo空歡喜一場。

 

出現上述狀況，即咱們所說的髒讀，兩個併發的事務，「事務A：領導給singo發工資」、「事務B：singo查詢工資帳戶」，事務B讀取了事務A還沒有提交的數據。

當隔離級別設置爲Read uncommitted時，就可能出現髒讀，如何避免髒讀，請看下一個隔離級別。

Read committed 讀提交

singo拿着工資卡去消費，系統讀取到卡里確實有2000元，而此時她的老婆也正好在網上轉帳，把singo工資卡的2000元轉到另外一帳戶，並在singo以前提交了事務，當singo扣款時，系統檢查到singo的工資卡已經沒有錢，扣款失敗，singo十分納悶，明明卡里有錢，爲什麼......

出現上述狀況，即咱們所說的不可重複讀，兩個併發的事務，「事務A：singo消費」、「事務B：singo的老婆網上轉帳」，事務A事先讀取了數據，事務B緊接了更新了數據，並提交了事務，而事務A再次讀取該數據時，數據已經發生了改變。

當隔離級別設置爲Read committed時，避免了髒讀，可是可能會形成不可重複讀。

大多數數據庫的默認級別就是Read committed，好比Sql Server , Oracle。如何解決不可重複讀這一問題，請看下一個隔離級別。

Repeatable read 重複讀

當隔離級別設置爲Repeatable read時，能夠避免不可重複讀。當singo拿着工資卡去消費時，一旦系統開始讀取工資卡信息（即事務開始），singo的老婆就不可能對該記錄進行修改，也就是singo的老婆不能在此時轉帳。

雖然Repeatable read避免了不可重複讀，但還有可能出現幻讀。

singo的老婆工做在銀行部門，她時常經過銀行內部系統查看singo的信用卡消費記錄。有一天，她正在查詢到singo當月信用卡的總消費金額（select sum(amount) from transaction where month = 本月）爲80元，而singo此時正好在外面胡吃海塞後在收銀臺買單，消費1000元，即新增了一條1000元的消費記錄（insert transaction ... ），並提交了事務，隨後singo的老婆將singo當月信用卡消費的明細打印到A4紙上，卻發現消費總額爲1080元，singo的老婆很詫異，覺得出現了幻覺，幻讀就這樣產生了。

注：MySQL的默認隔離級別就是Repeatable read。

Serializable 序列化

Serializable是最高的事務隔離級別，同時代價也花費最高，性能很低，通常不多使用，在該級別下，事務順序執行，不只能夠避免髒讀、不可重複讀，還避免了幻像讀。

 

 

 

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Innodb引擎室mysql server中支持事務的存儲引擎之一，

天然也是支持四種事務隔離級別的

read uncommitted，

read commit，

repeatable read

serializable，

下面就分別最四種隔離級別在實現的鎖機制作一個簡介：
serializable：

1:這種隔離級別對數據的要求最爲嚴格，天然也是性能最差的一種隔離級別。

在全部的select語句中都是默認加了一個lock in share mode的鎖，

2：在這種隔離級別中沒有一致讀的，全部的select都將返回最近的數據狀態。

3：因爲這種隔離級別的對數據高度一致的嚴格，因此會產生不少的鎖，天然也會致使不少的死鎖，對性能的影響不言而喻。

 

repeatable read：

1：全部的select在第一次一致讀之後在事務中都會使用同樣的數據狀態快照。

2：update，delete都會使用間隙鎖來保證數據的安全。防止phantom。

3：這是採用最廣的事務隔離級別，也是mysql默認的事務隔離級別。

 

read commited:

1:每個select都會使用各自的數據狀態的快照。

2:若是當前的數據狀態已更新到最新，可是噹噹個select的時候仍然會產生不一致的數據狀態。

3:更少的間隙鎖意味着更少的死鎖。

4:惟一key的檢查在第二索引和其它外鍵檢查的時候也會產生間隙所。（gap必須被鎖定以防止在parent row被刪除後仍在child row中插入相關數據）。

5:這種隔離級別也是使用的很是廣泛的隔離級別尤爲是在5.1之後的版本中。

6：徵對在5.0更早的版本中，能夠經過innodb_locks_unsafe_for_binlog移除gap locking。

（In V5.1, most gap-locking is removed w/ this level, but you MUST use row-based logging/replication。）

 

read uncommitted：

1：這種隔離級別幾乎不被使用，在selelct將會看到各類奇怪的數據現象，固然包括其它事務還未提交的數據。

2：強烈不推薦，不能保證數據的一致性。