大家好，歡迎來(lái)到Tlog4J課堂，我是Jensen。

面試官：數(shù)據(jù)庫(kù)事務(wù)的四大特性是什么?

候選人：ACID，分別指原子性、一致性、隔離性、持久性(得意~)

面試官：那在MySQL的InnoDB中，ACID是怎么保證的呢?

候選人：啊這……

ACID大家耳熟能詳，ACID是指數(shù)據(jù)庫(kù)事務(wù)中的基本特性：原子性、一致性、隔離性、持久性，那么這四種特性在MySql中是怎么保證的呢?或者說(shuō)，在InnoDB存儲(chǔ)引擎中，ACID是怎么實(shí)現(xiàn)的呢?這個(gè)在學(xué)校里的老師可沒(méi)教……

那今天咱們一起來(lái)看看，MySQL為了達(dá)成這四種特性做了一些什么事情。

首先，要回答這個(gè)問(wèn)題得了解清楚MySQL的日志體系，MySQL在InnoDB存儲(chǔ)引擎級(jí)別有兩種日志：undo log日志和redo log日志，那在MySQL Server級(jí)別又有一個(gè)binlog日志，咱們結(jié)合這幾個(gè)日志來(lái)說(shuō)明ACID特性。

Atomicity原子性保障

事務(wù)的原子性指一個(gè)事務(wù)(transaction)中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過(guò)程中發(fā)生錯(cuò)誤，會(huì)被回滾(Rollback)到事務(wù)開(kāi)始前的狀態(tài)，就像這個(gè)事務(wù)從來(lái)沒(méi)有執(zhí)行過(guò)一樣。

原子性是由undo log日志保證的，它記錄了需要回滾的日志信息，也就是說(shuō)我們的事務(wù)還沒(méi)提交需要回滾，那么事務(wù)回滾就是根據(jù)undo log日志來(lái)撤銷(xiāo)已經(jīng)執(zhí)行成功的SQL。

說(shuō)白了，undo log其實(shí)就是SQL的反向執(zhí)行，它記錄了反向執(zhí)行的SQL語(yǔ)句，把正向語(yǔ)句回滾回去。

Consistency一致性保障

事務(wù)的一致性指的是在一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫(kù)都必須處于一致性狀態(tài)。

如果事務(wù)成功地完成，那么系統(tǒng)中所有變化將正確地應(yīng)用，系統(tǒng)處于有效狀態(tài);如果在事務(wù)中出現(xiàn)錯(cuò)誤，那么系統(tǒng)中的所有變化將自動(dòng)地回滾，系統(tǒng)返回到原始狀態(tài)。

一致性是ACID的目的，也就是說(shuō)，只需要保證原子性、隔離性、持久性，自然也就保證了數(shù)據(jù)的一致性。

比如說(shuō)，我們的ID在數(shù)據(jù)庫(kù)中是唯一的，此時(shí)插入了一個(gè)唯一ID，數(shù)據(jù)庫(kù)會(huì)給我們做一個(gè)檢查，告訴咱們是否發(fā)生了主鍵沖突，如果主鍵沖突數(shù)據(jù)就無(wú)法插入。

另一部分是業(yè)務(wù)數(shù)據(jù)的一致性，這需要程序代碼來(lái)保證。

比如說(shuō)轉(zhuǎn)賬這個(gè)場(chǎng)景，假設(shè)我要轉(zhuǎn)賬100元出去，實(shí)際上數(shù)據(jù)庫(kù)中只有90元，那這時(shí)候就不應(yīng)該轉(zhuǎn)賬成功，這種情況通過(guò)數(shù)據(jù)庫(kù)是無(wú)法保證的，只能由程序來(lái)保證。

Isolation隔離性保障

事務(wù)的隔離性指的是在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí)，每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間，由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離。

事務(wù)查看數(shù)據(jù)更新時(shí)，數(shù)據(jù)所處的狀態(tài)要么是另一事務(wù)修改它之前的狀態(tài)，要么是另一事務(wù)修改它之后的狀態(tài)，事務(wù)不會(huì)查看到中間狀態(tài)的數(shù)據(jù)。

在MySQL中隔離性是通過(guò)MVCC多版本并發(fā)控制機(jī)制來(lái)保證的，它是在事務(wù)隔離級(jí)別中最最重要的一個(gè)概念，那它是怎么實(shí)現(xiàn)的呢?

多版本并發(fā)控制：讀取數(shù)據(jù)時(shí)通過(guò)一種類(lèi)似快照的方式將數(shù)據(jù)保存下來(lái)，這樣讀鎖和寫(xiě)鎖就不沖突了，不同事務(wù)的session會(huì)看到自己特定版本的數(shù)據(jù)，也就是版本鏈，通過(guò)版本鏈的概念來(lái)達(dá)到讀和寫(xiě)能夠并發(fā)進(jìn)行。

MVCC只在READ COMMITTED(已提交讀)和REPEATABLE READ(可重復(fù)讀)兩個(gè)隔離級(jí)別下工作，其他兩個(gè)隔離級(jí)別和MVCC不兼容，這是因?yàn)镽EAD UNCOMMITTED(讀未提交)總是讀取最新的數(shù)據(jù)行，而不是符合當(dāng)前事務(wù)版本的數(shù)據(jù)行，而ZERIALIZABLE(串行化)則會(huì)對(duì)所有讀取的行都加鎖，MVCC就沒(méi)有意義了。

在MySQL的InnoDB下，聚簇索引記錄中有兩個(gè)必要的隱藏列：

1. trx_id：它用來(lái)存儲(chǔ)每次對(duì)某條聚簇索引記錄進(jìn)行修改時(shí)的事務(wù)ID，這個(gè)事務(wù)ID由MySQL分配。
2. roll_pointer：每次對(duì)哪條聚簇索引記錄有修改的時(shí)候，都會(huì)把老版本寫(xiě)入undo日志中，這個(gè)roll_pointer就是存了一個(gè)指針，它指向這條聚簇索引記錄的上一個(gè)版本的位置，通過(guò)它來(lái)獲得上一個(gè)版本的記錄信息(注意插入操作的undo日志沒(méi)有這個(gè)屬性，因?yàn)樗鼪](méi)有老版本)。

OK，理解了這些概念，咱們?cè)賮?lái)看看MVCC。

已提交讀和可重復(fù)讀的區(qū)別就在于它們生成ReadView的策略不同。

MVCC就是版本鏈+ReadView所組成的這么一種概念，當(dāng)我們掌握了版本鏈和ReadView這兩個(gè)概念，也就明白了MVCC，我們接著來(lái)看看這個(gè)ReadView。

我們?cè)陂_(kāi)啟事務(wù)時(shí)創(chuàng)建ReadView，ReadView維護(hù)了當(dāng)前活動(dòng)的事務(wù)ID，即未提交的正在進(jìn)行中的事務(wù)ID，排序生成一個(gè)數(shù)組訪問(wèn)數(shù)據(jù)，獲取需要修改的記錄中的事務(wù)ID(獲取的是事務(wù)ID最大的記錄)，然后去對(duì)比ReadView：

• 如果獲取的事務(wù)ID在ReadView的左邊(比ReadView都小)，表示可以訪問(wèn)(在左邊意味著該事務(wù)已經(jīng)提交)。
• 如果獲取的事務(wù)ID在ReadView的右邊(比ReadView都大)，或者就在ReadView中，表示不可以訪問(wèn)，獲取roll_pointer，取上一版本重新對(duì)比(在右邊意味著，該事務(wù)在ReadView生成之后出現(xiàn)，在ReadView中意味著該事務(wù)還未提交)。

已提交讀隔離級(jí)別下的事務(wù)在每次查詢(xún)的開(kāi)始都會(huì)生成一個(gè)獨(dú)立的ReadView，也就是說(shuō)我每次select查出來(lái)的ReadView都會(huì)重新生成，所以ReadView可能會(huì)不一樣，就是說(shuō)讀到的數(shù)據(jù)就會(huì)不一樣;

而可重復(fù)讀隔離級(jí)別則在第一次讀的時(shí)候生成一個(gè)ReadView，之后的讀都復(fù)用之前的ReadView，每次select查詢(xún)都是一樣的。

在這里咱們發(fā)現(xiàn)了這兩者的性能是有差別的，MySQL為了提高查詢(xún)性能，默認(rèn)使用了可重復(fù)讀這種隔離級(jí)別(原因之一)。

這就是MySQL的MVCC，通過(guò)版本鏈，實(shí)現(xiàn)多版本可并發(fā)讀-寫(xiě)、寫(xiě)-讀，通過(guò)ReadView生成策略的不同實(shí)現(xiàn)不同的隔離級(jí)別。

Durability持久性保障

事務(wù)的持久性指的是只要事務(wù)成功結(jié)束，它對(duì)數(shù)據(jù)庫(kù)所做的更新就必須永久保存下來(lái)，即使發(fā)生系統(tǒng)崩潰，重新啟動(dòng)數(shù)據(jù)庫(kù)系統(tǒng)后，數(shù)據(jù)庫(kù)還能恢復(fù)到事務(wù)成功結(jié)束時(shí)的狀態(tài)。

持久性意味著事務(wù)操作最終要持久化到數(shù)據(jù)庫(kù)中，持久性是由 內(nèi)存+redo log來(lái)保證的，MySQL的InnoDB在修改數(shù)據(jù)的時(shí)候，同時(shí)在內(nèi)存和redo log記錄這次操作，宕機(jī)的時(shí)候可以從redo log中恢復(fù)數(shù)據(jù)。

同時(shí)，我們都知道MySQL Server的主從同步就是通過(guò)binlog來(lái)實(shí)現(xiàn)的，從服務(wù)器通過(guò)binlog文件的SQL拿過(guò)去執(zhí)行一遍，保證跟主服務(wù)器的數(shù)據(jù)一致，而binlog和redo log都存儲(chǔ)了表中的數(shù)據(jù)，都可以用來(lái)做數(shù)據(jù)恢復(fù)的，那怎么保證binlog和redo log的數(shù)據(jù)一致呢?

下面是InnoDB下redo log的過(guò)程：

1. 對(duì)redo log進(jìn)行寫(xiě)盤(pán)，寫(xiě)完后事務(wù)進(jìn)入prepare狀態(tài)。
2. 如果前面prepare成功，馬上就會(huì)進(jìn)行binlog寫(xiě)盤(pán)，再繼續(xù)將事務(wù)日志持久化到binlog。
3. 如果binlog持久化成功，那么事務(wù)則進(jìn)入commit狀態(tài)(在redo log里面寫(xiě)一條commit記錄)。

這意味著一個(gè)事務(wù)到底有沒(méi)有成功，由兩方面來(lái)保證：第一是redo log里面有沒(méi)有commit記錄，如果有commit記錄，那么binlog一定是持久化成功了，也就是說(shuō)事務(wù)成功了。

再者就是redo log最終還會(huì)進(jìn)行刷盤(pán)，它的刷盤(pán)會(huì)在系統(tǒng)空閑時(shí)進(jìn)行，并不是寫(xiě)到redo log時(shí)馬上進(jìn)行刷盤(pán)。

以上就是數(shù)據(jù)庫(kù)的基本特性ACID在MySQL中如何進(jìn)行保證的方法，ACID就是這樣通過(guò)InnoDB的幾個(gè)日志和MVCC來(lái)保證原子性、一致性、隔離性、持久化的。

最后，再問(wèn)大家一個(gè)問(wèn)題：MySQL是先設(shè)計(jì)ACID特性才有的底層實(shí)現(xiàn)，還是先實(shí)現(xiàn)了底層才總結(jié)出ACID特性的呢?