1. 程式人生 > >MySQL ACID及四種隔離級別的解釋

MySQL ACID及四種隔離級別的解釋

失敗 操作 mage city 而且 tab 過多 保存 事務提交

以下內容出自《高性能MySQL》第三版,了解事務的ACID及四種隔離級有助於我們更好的理解事務運作。

下面舉一個銀行應用是解釋事務必要性的一個經典例子。假如一個銀行的數據庫有兩張表:支票表(checking)和儲蓄表(savings)。現在要從用戶Jane的支票賬戶轉移200美元到她的儲蓄賬戶,那麽至少需要三個步驟:

1、檢查支票賬戶的余額高於或者等於200美元。

2、從支票賬戶余額中減去200美元。

3、在儲蓄帳戶余額中增加200美元。

上述三個步驟的操作必須打包在一個事務中,任何一個步驟失敗,則必須回滾所有的步驟。

可以用START TRANSACTION語句開始一個事務,然後要麽使用COMMIT提交將修改的數據持久保存,要麽使用ROLLBACK撤銷所有的修改。事務SQL的樣本如下:

1. start transaction;

2. select balance from checking where customer_id = 10233276;

3. update checking set balance = balance - 200.00 where customer_id = 10233276;

4. update savings set balance = balance + 200.00 where customer_id = 10233276;

5. commit;

ACID表示原子性(atomicity)、一致性(consistency)、隔離性(isolation)和持久性(durability)。一個很好的事務處理系統,必須具備這些標準特性:

原子性(atomicity)

  一個事務必須被視為一個不可分割的最小工作單元,整個事務中的所有操作要麽全部提交成功,要麽全部失敗回滾,對於一個事務來說,不可能只執行其中的一部分操作,這就是事務的原子性

一致性(consistency)

數據庫總是從一個一致性的狀態轉換到另一個一致性的狀態。(在前面的例子中,一致性確保了,即使在執行第三、四條語句之間時系統崩潰,支票賬戶中也不會損失200美元,因為事務最終沒有提交,所以事務中所做的修改也不會保存到數據庫中。)

隔離性(isolation)

通常來說,一個事務所做的修改在最終提交以前,對其他事務是不可見的。(在前面的例子中,當執行完第三條語句、第四條語句還未開始時,此時有另外的一個賬戶匯總程序開始運行,則其看到支票帳戶的余額並沒有被減去200美元。)

持久性(durability)

  一旦事務提交,則其所做的修改不會永久保存到數據庫。(此時即使系統崩潰,修改的數據也不會丟失。持久性是個有占模糊的概念,因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障,而有些則未必,而且不可能有能做到100%的持久性保證的策略。)

隔離級別:

READ UNCOMMITTED(未提交讀)

  在READ UNCOMMITTED級別,事務中的修改,即使沒有提交,對其他事務也都是可見的。事務可以讀取未提交的數據,這也被稱為臟讀(Dirty Read)。這個級別會導致很多問題,從性能上來說,READ UNCOMMITTED不會比其他的級別好太多,但卻缺乏其他級別的很多好處,除非真的有非常必要的理由,在實際應用中一般很少使用。

READ COMMITTED(提交讀)

  大多數數據庫系統的默認隔離級別都是READ COMMTTED(但MySQL不是)。READ COMMITTED滿足前面提到的隔離性的簡單定義:一個事務開始時,只能"看見"已經提交的事務所做的修改。換句話說,一個事務從開始直到提交之前,所做的任何修改對其他事務都是不可見的。這個級別有時候叫做不可重復讀(nonrepeatble read),因為兩次執行同樣的查詢,可能會得到不一樣的結果

REPEATABLE READ(可重復讀)

  REPEATABLE READ解決了臟讀的問題。該隔離級別保證了在同一個事務中多次讀取同樣記錄結果是一致的。但是理論上,可重復讀隔離級別還是無法解決另外一個幻讀(Phantom Read)的問題。所謂幻讀,指的是當某個事務在讀取某個範圍內的記錄時,另一個事務又在該範圍內插入了新的記錄,當之前的事務再次讀取該範圍的記錄時,會產生幻行(Phantom Row)。InnoDB和XtraDB存儲引擎通過多版本並發控制(MVCC,Multiversion Concurrency Control)解決了幻讀的問題。

SERIALIZABLE(可串行化)

  SERIALIZABLE是最高的隔離級別。它通過強制事務串行執行,避免了前面說的幻讀的問題。簡單來說,SERIALIZABLE會在讀取每一行數據都加鎖,所以可能導致大量的超時和鎖爭用問題。實際應用中也很少用到這個隔離級別,只有在非常需要確保數據的一致性而且可以接受沒有並發的情況下,才考慮采用該級別。

打鉤說明該隔離級別還存在這種情況,打X代表該隔離級別已經解決了這種情況:

技術分享圖片

MySQL ACID及四種隔離級別的解釋