面試官：數據庫事務的ACID靠什么來保證？
大家好，歡迎來到Tlog4J課堂，我是Jensen。
面試官：數據庫事務的四大特性是什么?
候選人：ACID，分別指原子性、一致性、隔離性、持久性(得意~)
面試官：那在MySQL的InnoDB中，ACID是怎么保證的呢?
候選人：啊這……
ACID大家耳熟能詳，ACID是指數據庫事務中的基本特性：原子性、一致性、隔離性、持久性，那么這四種特性在MySql中是怎么保證的呢?或者說，在InnoDB存儲引擎中，ACID是怎么實現的呢?這個在學校里的老師可沒教……
那今天咱們一起來看看，MySQL為了達成這四種特性做了一些什么事情。
首先，要回答這個問題得了解清楚MySQL的日志體系，MySQL在InnoDB存儲引擎級別有兩種日志：undo log日志和redo log日志，那在MySQL Server級別又有一個binlog日志，咱們結合這幾個日志來說明ACID特性。
Atomicity原子性保障
事務的原子性指一個事務(transaction)中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾(Rollback)到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
原子性是由undo log日志保證的，它記錄了需要回滾的日志信息，也就是說我們的事務還沒提交需要回滾，那么事務回滾就是根據undo log日志來撤銷已經執行成功的SQL。
說白了，undo log其實就是SQL的反向執行，它記錄了反向執行的SQL語句，把正向語句回滾回去。
Consistency一致性保障
事務的一致性指的是在一個事務執行之前和執行之后數據庫都必須處于一致性狀態。
如果事務成功地完成，那么系統中所有變化將正確地應用，系統處于有效狀態;如果在事務中出現錯誤，那么系統中的所有變化將自動地回滾，系統返回到原始狀態。
一致性是ACID的目的，也就是說，只需要保證原子性、隔離性、持久性，自然也就保證了數據的一致性。
比如說，我們的ID在數據庫中是唯一的，此時插入了一個唯一ID，數據庫會給我們做一個檢查，告訴咱們是否發生了主鍵沖突，如果主鍵沖突數據就無法插入。
另一部分是業務數據的一致性，這需要程序代碼來保證。
比如說轉賬這個場景，假設我要轉賬100元出去，實際上數據庫中只有90元，那這時候就不應該轉賬成功，這種情況通過數據庫是無法保證的，只能由程序來保證。
Isolation隔離性保障
事務的隔離性指的是在并發環境中，當不同的事務同時操縱相同的數據時，每個事務都有各自的完整數據空間，由并發事務所做的修改必須與任何其他并發事務所做的修改隔離。
事務查看數據更新時，數據所處的狀態要么是另一事務修改它之前的狀態，要么是另一事務修改它之后的狀態，事務不會查看到中間狀態的數據。
在MySQL中隔離性是通過MVCC多版本并發控制機制來保證的，它是在事務隔離級別中最最重要的一個概念，那它是怎么實現的呢?
多版本并發控制：讀取數據時通過一種類似快照的方式將數據保存下來，這樣讀鎖和寫鎖就不沖突了，不同事務的session會看到自己特定版本的數據，也就是版本鏈，通過版本鏈的概念來達到讀和寫能夠并發進行。
MVCC只在READ COMMITTED(已提交讀)和REPEATABLE READ(可重復讀)兩個隔離級別下工作，其他兩個隔離級別和MVCC不兼容，這是因為READ UNCOMMITTED(讀未提交)總是讀取最新的數據行，而不是符合當前事務版本的數據行，而ZERIALIZABLE(串行化)則會對所有讀取的行都加鎖，MVCC就沒有意義了。
在MySQL的InnoDB下，聚簇索引記錄中有兩個必要的隱藏列：
- trx_id：它用來存儲每次對某條聚簇索引記錄進行修改時的事務ID，這個事務ID由MySQL分配。
- roll_pointer：每次對哪條聚簇索引記錄有修改的時候，都會把老版本寫入undo日志中，這個roll_pointer就是存了一個指針，它指向這條聚簇索引記錄的上一個版本的位置，通過它來獲得上一個版本的記錄信息(注意插入操作的undo日志沒有這個屬性，因為它沒有老版本)。
OK，理解了這些概念，咱們再來看看MVCC。
已提交讀和可重復讀的區別就在于它們生成ReadView的策略不同。
MVCC就是版本鏈+ReadView所組成的這么一種概念，當我們掌握了版本鏈和ReadView這兩個概念，也就明白了MVCC，我們接著來看看這個ReadView。
我們在開啟事務時創建ReadView，ReadView維護了當前活動的事務ID，即未提交的正在進行中的事務ID，排序生成一個數組訪問數據，獲取需要修改的記錄中的事務ID(獲取的是事務ID最大的記錄)，然后去對比ReadView：
- 如果獲取的事務ID在ReadView的左邊(比ReadView都小)，表示可以訪問(在左邊意味著該事務已經提交)。
- 如果獲取的事務ID在ReadView的右邊(比ReadView都大)，或者就在ReadView中，表示不可以訪問，獲取roll_pointer，取上一版本重新對比(在右邊意味著，該事務在ReadView生成之后出現，在ReadView中意味著該事務還未提交)。
已提交讀隔離級別下的事務在每次查詢的開始都會生成一個獨立的ReadView，也就是說我每次select查出來的ReadView都會重新生成，所以ReadView可能會不一樣，就是說讀到的數據就會不一樣;
而可重復讀隔離級別則在第一次讀的時候生成一個ReadView，之后的讀都復用之前的ReadView，每次select查詢都是一樣的。
在這里咱們發現了這兩者的性能是有差別的，MySQL為了提高查詢性能，默認使用了可重復讀這種隔離級別(原因之一)。
這就是MySQL的MVCC，通過版本鏈，實現多版本可并發讀-寫、寫-讀，通過ReadView生成策略的不同實現不同的隔離級別。
Durability持久性保障
事務的持久性指的是只要事務成功結束，它對數據庫所做的更新就必須永久保存下來，即使發生系統崩潰，重新啟動數據庫系統后，數據庫還能恢復到事務成功結束時的狀態。
持久性意味著事務操作最終要持久化到數據庫中，持久性是由 內存+redo log來保證的，MySQL的InnoDB在修改數據的時候，同時在內存和redo log記錄這次操作，宕機的時候可以從redo log中恢復數據。
同時，我們都知道MySQL Server的主從同步就是通過binlog來實現的，從服務器通過binlog文件的SQL拿過去執行一遍，保證跟主服務器的數據一致，而binlog和redo log都存儲了表中的數據，都可以用來做數據恢復的，那怎么保證binlog和redo log的數據一致呢?
下面是InnoDB下redo log的過程：
- 對redo log進行寫盤，寫完后事務進入prepare狀態。
- 如果前面prepare成功，馬上就會進行binlog寫盤，再繼續將事務日志持久化到binlog。
- 如果binlog持久化成功，那么事務則進入commit狀態(在redo log里面寫一條commit記錄)。
這意味著一個事務到底有沒有成功，由兩方面來保證：第一是redo log里面有沒有commit記錄，如果有commit記錄，那么binlog一定是持久化成功了，也就是說事務成功了。
再者就是redo log最終還會進行刷盤，它的刷盤會在系統空閑時進行，并不是寫到redo log時馬上進行刷盤。
以上就是數據庫的基本特性ACID在MySQL中如何進行保證的方法，ACID就是這樣通過InnoDB的幾個日志和MVCC來保證原子性、一致性、隔離性、持久化的。
最后，再問大家一個問題：MySQL是先設計ACID特性才有的底層實現，還是先實現了底層才總結出ACID特性的呢?
