RR 級別的幻讀

有了鎖和 MVCC , 事務(wù)的隔離性得到解決。這里要引申一下，默認(rèn)的 RR 的級別，解決了幻讀嗎？幻讀通常針對的是?INSERT,?不可重復(fù)度則針對?UPDATE 。

我們期望是

id??name
1???A
2???B

實(shí)際卻是

id??name
1???B
2???B

其實(shí)在 MySQL 可重復(fù)讀的隔離級別中并不是完全解決了幻讀的問題，而是解決了讀數(shù)據(jù)情況下的幻讀問題。而對于修改的操作依舊存在幻讀問題，就是說 MVCC 對于幻讀的解決時(shí)不徹底的。

原子性

接著說說原子性。前文有提到 undo log ，回滾日志。隔離性的MVCC其實(shí)就是依靠它來實(shí)現(xiàn)的，原子性也是。實(shí)現(xiàn)原子性的關(guān)鍵，是當(dāng)事務(wù)回滾時(shí)能夠撤銷所有已經(jīng)成功執(zhí)行的sql語句。

當(dāng)事務(wù)對數(shù)據(jù)庫進(jìn)行修改時(shí)，InnoDB會生成對應(yīng)的 undo log；如果事務(wù)執(zhí)行失敗或調(diào)用了 rollback，導(dǎo)致事務(wù)需要回滾，便可以利用 undo log 中的信息將數(shù)據(jù)回滾到修改之前的樣子。undo log 屬于邏輯日志，它記錄的是sql執(zhí)行相關(guān)的信息。當(dāng)發(fā)生回滾時(shí)，InnoDB 會根據(jù) undo log 的內(nèi)容做與之前相反的工作：

• 對于每個 insert，回滾時(shí)會執(zhí)行 delete；
• 對于每個 delete，回滾時(shí)會執(zhí)行insert；
• 對于每個 update，回滾時(shí)會執(zhí)行一個相反的 update，把數(shù)據(jù)改回去。

以update操作為例：當(dāng)事務(wù)執(zhí)行update時(shí)，其生成的undo log中會包含被修改行的主鍵(以便知道修改了哪些行)、修改了哪些列、這些列在修改前后的值等信息，回滾時(shí)便可以使用這些信息將數(shù)據(jù)還原到update之前的狀態(tài)。

持久性

Innnodb有很多 log，持久性靠的是 redo log。

一條SQL更新語句怎么運(yùn)行

持久性肯定和寫有關(guān)，MySQL 里經(jīng)常說到的 WAL 技術(shù)，WAL 的全稱是 Write-Ahead Logging，它的關(guān)鍵點(diǎn)就是先寫日志，再寫磁盤。就像小店做生意，有個粉板，有個賬本，來客了先寫粉板，等不忙的時(shí)候再寫賬本。

redo log

redo log 就是這個粉板，當(dāng)有一條記錄要更新時(shí)，InnoDB 引擎就會先把記錄寫到 redo log（并更新內(nèi)存），這個時(shí)候更新就算完成了。在適當(dāng)?shù)臅r(shí)候，將這個操作記錄更新到磁盤里面，而這個更新往往是在系統(tǒng)比較空閑的時(shí)候做，這就像打烊以后掌柜做的事。

redo log 有兩個特點(diǎn)：

• 大小固定，循環(huán)寫
• crash-safe

對于redo log 是有兩階段的：commit 和 prepare 如果不使用“兩階段提交”，數(shù)據(jù)庫的狀態(tài)就有可能和用它的日志恢復(fù)出來的庫的狀態(tài)不一致. 好了，先到這里，看看另一個。

Buffer Pool

InnoDB還提供了緩存，Buffer Pool 中包含了磁盤中部分?jǐn)?shù)據(jù)頁的映射，作為訪問數(shù)據(jù)庫的緩沖：

• 當(dāng)讀取數(shù)據(jù)時(shí)，會先從Buffer Pool中讀取，如果Buffer Pool中沒有，則從磁盤讀取后放入Buffer Pool；
• 當(dāng)向數(shù)據(jù)庫寫入數(shù)據(jù)時(shí)，會首先寫入Buffer Pool，Buffer Pool中修改的數(shù)據(jù)會定期刷新到磁盤中。

Buffer Pool 的使用大大提高了讀寫數(shù)據(jù)的效率，但是也帶了新的問題：如果MySQL宕機(jī)，而此時(shí) Buffer Pool 中修改的數(shù)據(jù)還沒有刷新到磁盤，就會導(dǎo)致數(shù)據(jù)的丟失，事務(wù)的持久性無法保證。

所以加入了 redo log。當(dāng)數(shù)據(jù)修改時(shí)，除了修改Buffer Pool中的數(shù)據(jù)，還會在redo log記錄這次操作；

當(dāng)事務(wù)提交時(shí)，會調(diào)用fsync接口對redo log進(jìn)行刷盤。

如果MySQL宕機(jī)，重啟時(shí)可以讀取redo log中的數(shù)據(jù)，對數(shù)據(jù)庫進(jìn)行恢復(fù)。

redo log采用的是WAL（Write-ahead logging，預(yù)寫式日志），所有修改先寫入日志，再更新到Buffer Pool，保證了數(shù)據(jù)不會因MySQL宕機(jī)而丟失，從而滿足了持久性要求。而且這樣做還有兩個優(yōu)點(diǎn)：

• 刷臟頁是隨機(jī) IO，redo log 順序 IO
• 刷臟頁以Page為單位，一個Page上的修改整頁都要寫；而redo log 只包含真正需要寫入的，無效 IO 減少。

binlog

說到這，可能會疑問還有個 bin log 也是寫操作并用于數(shù)據(jù)的恢復(fù)，有啥區(qū)別呢。

• 層次：redo log 是 innoDB 引擎特有的，server 層的叫 binlog(歸檔日志)
• 內(nèi)容：redolog 是物理日志，記錄“在某個數(shù)據(jù)頁上做了什么修改”；binlog 是邏輯日志，是語句的原始邏輯，如“給 ID=2 這一行的 c 字段加 1 ”
• 寫入：redolog 循環(huán)寫且寫入時(shí)機(jī)較多，binlog 追加且在事務(wù)提交時(shí)寫入

binlog 和 redo log

對于語句?update T set c=c+1 where ID=2;

1. 執(zhí)行器先找引擎取 ID=2 這一行。ID 是主鍵，直接用樹搜索找到。如果 ID = 2 這一行所在數(shù)據(jù)頁就在內(nèi)存中，就直接返回給執(zhí)行器；否則，需要先從磁盤讀入內(nèi)存，再返回。
2. 執(zhí)行器拿到引擎給的行數(shù)據(jù)，把這個值加上 1，N+1，得到新的一行數(shù)據(jù)，再調(diào)用引擎接口寫入這行新數(shù)據(jù)。
3. 引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時(shí)將這個更新操作記錄到 redo log 里面，此時(shí) redo log 處于 prepare 狀態(tài)。然后告知執(zhí)行器執(zhí)行完成了，隨時(shí)可以提交事務(wù)。
4. 執(zhí)行器生成這個操作的 binlog，并把 binlog 寫入磁盤。
5. 執(zhí)行器調(diào)用引擎的提交事務(wù)接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態(tài)，更新完成

為什么先寫 redo log 呢 ？

• 先 redo 后 bin : binlog 丟失，少了一次更新，恢復(fù)后仍是0。
• 先 bin 后 redo : 多了一次事務(wù)，恢復(fù)后是1。

一致性

一致性是事務(wù)追求的最終目標(biāo)，前問所訴的原子性、持久性和隔離性，其實(shí)都是為了保證數(shù)據(jù)庫狀態(tài)的一致性。當(dāng)然，上文都是數(shù)據(jù)庫層面的保障，一致性的實(shí)現(xiàn)也需要應(yīng)用層面進(jìn)行保障。

也就是你的業(yè)務(wù)，比如購買操作只扣除用戶的余額，不減庫存，肯定無法保證狀態(tài)的一致。

總結(jié)

MySQL 都很熟， ACID 也知道是個啥，但 MySQL 的 ACID 怎么實(shí)現(xiàn)的？

有時(shí)候，就像你知道了有 undo log、redo log 但可能并不太清楚為什么有，當(dāng)知道了設(shè)計(jì)的目的，了解起來就會更加清晰了。