事務的四大特性和隔離級別

一．什麼是事務 
事務是應用程序中一系列嚴密的操做，全部操做必須成功完成，不然在每一個操做中所做的全部更改都會被撤消。

二．事務的 四個特性（ACID ）
事務具備四個特性：原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（ Isolation ）和持久性（ Durability ）。這四個特性簡稱爲 ACID 特性。

1、事務的原子性(Atomicity)

原子性要求事務所包含的所有操做是一個不可分割的總體，這些操做要麼所有提交成功，要麼只要其中一個操做失敗，就所有不執行。

2、事務的一致性(Consistency)

一致性要求事務所包含的操做不能違反數據資源的一致性檢查，數據資源在事務執行以前處於一個數據的一致性狀態，那麼，事務執行以後也須要依然保持數據間的一致性狀態。

例如： 對於一個證券系統來講，若是顧客銀行帳戶和證券帳戶資金總和爲10萬的話(銀行帳戶初始8萬，證券帳戶初始2萬)，從銀行帳戶的8萬轉帳5萬到證券帳戶的事務操做結束以後，銀行帳戶會剩餘3萬，證券帳戶爲7萬，兩個帳戶的總和依然是10萬，若是事務操做結束後，整個數據狀態不是這個樣子，那麼就說系統處於不一致狀態，而使用事務其中一個目的就是爲了不這種不一致性狀態的產生。

3、事務的隔離性(Isolation)

事務的隔離性主要規定了各個事務之間相互影響的程度。隔離性概念主要面向對數據資源的併發訪問(Concurrency)，併兼顧影響事務的一致性。當兩個事務或者更多事務同時訪問同一數據資源的時候，不一樣的隔離級別決定了各個事務對該數據資源訪問的不一樣行爲。

事務的隔離級別，隔離程度按照從弱到強分別爲「Read Uncommitted (未提交讀)」，「Read Committed（提交讀）」，「Repeatable Read（可重複讀）」和「Serializable（序列化）」

4、事務的持久性(Durability)

事務的持久性是指一旦整個事務操做成功提交完成，對數據所作的變動將被記載並不可逆轉，

3、事務的隔離級別 詳解

對於數據庫來講，一般都有一個默認的隔離級別，大多數狀況下都是ReadCommitted。

Oracle默認的是ReadCommitted。

MySQL的默認事務隔離級別是Repeatable Read。

並不是全部的數據庫都支持這四種隔離級別，好比Oracle只支持Read Committed和Serializable，Mysql支持這四種。若是你指定的隔離級別當前數據庫不支持的話，數據庫會採用默認的隔離級別代替你指定的隔離級別。

READ_UNCOMMITTED： 會出現髒讀、不可重複讀、幻讀 (讀數據時不加鎖 )
READ_COMMITTED：  會出現不可重複讀、幻讀問題【鎖定正在讀取的行。 在讀數據以前加一個讀鎖，讀完以後釋放鎖】
REPEATABLE_READ： 會出幻讀【鎖定所讀取的全部行。在讀數據以前，加一個讀鎖，讀完以後不釋放鎖，直到事務rollback或者commit後才釋放鎖】
SERIALIZABLE： 保證全部的狀況不會發生。【鎖表。在讀數據以前，加鎖（稱爲條件鎖），讀完以後不釋放鎖，直到事務rollback或者commit後才釋放鎖】

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

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的老婆很詫異，覺得出現了幻覺，幻讀就這樣產生了。

Serializable 序列化

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

 結論：在MySQL/InnoDB中，所謂的讀不加鎖，並不適用於全部的狀況，而是隔離級別相關的。Serializable隔離級別，讀不加鎖就再也不成立，全部的讀操做，都是當前讀，加讀鎖

隔離級別：Isolation Level，也是RDBMS的一個關鍵特性。相信對數據庫有所瞭解的朋友，對於4種隔離級別：Read Uncommited，Read Committed，Repeatable Read，Serializable，都有了深刻的認識。本文不打算討論數據庫理論中，是如何定義這4種隔離級別的含義的，而是跟你們介紹一下MySQL/InnoDB是如何定義這4種隔離級別的。

 

MySQL/InnoDB定義的4種隔離級別：

• Read Uncommited

  能夠讀取未提交記錄。此隔離級別，不會使用，忽略。

• Read Committed (RC)

  快照讀忽略，本文不考慮。

  針對當前讀，RC隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，存在幻讀現象。

• Repeatable Read (RR)

  快照讀忽略，本文不考慮。

  針對當前讀，RR隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，同時保證對讀取的範圍加鎖，新的知足查詢條件的記錄不可以插入 (間隙鎖)，不存在幻讀現象。

• Serializable

  從MVCC併發控制退化爲基於鎖的併發控制。不區別快照讀與當前讀，全部的讀操做均爲當前讀，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)。

  Serializable隔離級別下，讀寫衝突，所以併發度急劇降低，在MySQL/InnoDB下不建議使用。