0. 說明

前兩天有件事遇到了事務的特性和隔離級别的問題，（什麼事，你懂的）。今天就總結下這兩個内容，主要參考的是《高性能MySQL》這本巨著。

1. 事務的四大特性

事務的四大特性（ACID），顧名思義，就是4個特性，先看下圖：

事務的四大特性

下面我們具體看下在書中四大特性的概念。

1.1 原子性

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

1.2 一緻性

數據庫總是從一個一緻性的狀态轉換到另外一個一緻性的狀态。在著名的轉賬的例子中，一緻性确保了無論中間的那條語句執行時系統崩潰，或者其他原因導緻語句執行失敗，支票賬戶中也不會損失，因為事務最終沒有被提交，所以事務中所做的修改也不會被保存在數據庫中。

1.3 隔離性

通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。在著名的轉賬的例子中，當事務沒有提交的時候，轉賬的語句執行了，此時有另外一個賬戶彙總程序開始運行，則其看到的支票賬戶的餘額并沒有改變。後面我們讨論隔離級别的時候，會發現為什麼我們要說“通常來說”是不可見的。

1.4 持久性

一旦事務提交，則其所做的修改就會被永遠保存到數據庫中。此時即便是系統崩潰，修改的數據也不會丢失。持久性是個有點模糊的概念，因為實際上持久性也分很多不同的級别。有些持久性策略能夠提供非常強的安全保障，而有些則未必。而且不能有能做到100%的持久性保證的策略（如果數據庫本身就能做到真正的持久性，那麼備份又怎麼能增加持久性呢？）。這個在上面說到的這本巨著中會詳細的讨論MySQL中持久性的真正含義。

2. 事務的隔離級别

事務的隔離級别主要是講事務的隔離性。主要是不同事務之間的可見性問題，還是先看下圖：

事務的隔離級别

下面主要看下書中講的事務的四個隔離級别。

2.1 未提交讀

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

2.2 提交讀

大多數數據庫系統的默認隔離級别是Read Committed(但MySQL不是)。Read Committed滿足前面提到的隔離性的簡單定義：一個事務開始時，隻能“看見”已經提交的事務所做的修改。換句話說，一個事務從開始知道提交之前，所做的任何修改對其他事務都是不可見的。這個級别有時候也叫做不可重複讀（nonrepeatable read），因為兩次執行同樣的查詢，可能會得到不一樣的結果。

2.3 可重複讀

Repeatable Read解決了髒讀的問題。該級别保證了在同一個事務中多次讀取同樣記錄的結果是一緻的。但是理論上，可重複讀隔離級别還是無法解決另外一個幻讀（Phantom Read）的問題。所謂幻讀，指的是當某個事務在讀取某個範圍内的記錄時，另外一個事務又在該範圍内插入新的記錄，當之前的事務再次讀取該範圍的記錄時，會産生幻行（Phantom Row）。InnoDB和XtraDB存儲引擎通過多版本并發控制（MVCC,Multiversion Concurrency Control）解決了幻讀的問題。**可重複讀是MySQL的默認事務隔離級别**。

2.4 可串行化

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

3. 總結

對于事務的四大特性，沒什麼說的，就是一些保證數據一緻性的特點。這些特點也會适用于現在流行的分布式系統中的分布式事務中。事務的隔離級别是一個比較難懂的問題，因為可能會導緻髒讀，幻讀，不可重複讀，或者性能為題，這個我們後面有機會再出文章解釋，需要的可以先關注下本公衆号。希望本文能對各位看客理解數據庫事務有所幫助。

求評論、點贊、關注 轉發。

限于筆者知識有限，如果不足之處請幫忙指正，不喜勿噴！

您的支持是我不懈努力的動力，請讀者多支持下！

更多文章，請關注微信公衆号 CS_Toper之路，或者頭條号 CSToper。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!