還記得剛上研究生的時(shí)候，導(dǎo)師常掛在嘴邊的一句話，“科研的基礎(chǔ)不過(guò)就是數(shù)據(jù)而已。”如今看來(lái)，無(wú)論是人文社科，還是自然科學(xué)，或許都可在一定程度上看作是數(shù)據(jù)的科學(xué)。

倘若剝開(kāi)研究領(lǐng)域的外衣，將人的操作抽象出來(lái)，那么科研的過(guò)程大概就是根據(jù)數(shù)據(jù)流動(dòng)探索其中的未知信息吧。當(dāng)然科學(xué)研究的范疇涵蓋甚廣，也不是一兩句話能夠拎得清的。不過(guò)從這個(gè)角度上的闡述，也只是為了引出數(shù)據(jù)的重要性。

在當(dāng)今社會(huì)，充斥著大量的數(shù)據(jù)。從眾多APP上的賬戶資料到銀行信用體系等個(gè)人檔案，都離不開(kāi)對(duì)大量數(shù)據(jù)的組織、存儲(chǔ)和管理。而這，便是數(shù)據(jù)庫(kù)存在的目的和價(jià)值。

目前數(shù)據(jù)庫(kù)的類型主要分為兩種，一種是關(guān)系型數(shù)據(jù)庫(kù)，另一種是非關(guān)系型數(shù)據(jù)庫(kù)（NoSQL）。而我們今天的主角MySQL就是關(guān)系型數(shù)據(jù)庫(kù)中的一種。

本文結(jié)構(gòu)

關(guān)系型數(shù)據(jù)庫(kù)與NoSQL

關(guān)系型數(shù)據(jù)庫(kù)，顧名思義，是指存儲(chǔ)的數(shù)據(jù)之間具有關(guān)系。這種所謂的關(guān)系通常用二維表格中的行列來(lái)表示，即一個(gè)二維表的邏輯結(jié)構(gòu)能夠反映表中數(shù)據(jù)的存儲(chǔ)關(guān)系。

概念總是拗口難懂的。那么簡(jiǎn)單來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)就是按照表格進(jìn)行的。數(shù)據(jù)的存儲(chǔ)實(shí)際上就是對(duì)一個(gè)或者多個(gè)表格的存儲(chǔ)。通過(guò)對(duì)這些表格進(jìn)行分類、合并、連接或者選取等運(yùn)算來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)的管理。常見(jiàn)的關(guān)系型數(shù)據(jù)庫(kù)有MySQL、Oracle、DB2和SqlServer等。

非關(guān)系型數(shù)據(jù)庫(kù)（NoSQL）是相對(duì)于關(guān)系型數(shù)據(jù)庫(kù)的一種泛指，它的特點(diǎn)是去掉了關(guān)系型數(shù)據(jù)庫(kù)中的關(guān)系特性，從而可獲得更好的擴(kuò)展性。NoSQL并沒(méi)有嚴(yán)格的存儲(chǔ)方式，但采用不同的存儲(chǔ)結(jié)構(gòu)都是為了獲得更高的性能和更高的并發(fā)。

NoSQL根據(jù)存儲(chǔ)方式可分為四大類，鍵值存儲(chǔ)數(shù)據(jù)庫(kù)、列存儲(chǔ)數(shù)據(jù)庫(kù)、文檔型數(shù)據(jù)庫(kù)和圖形數(shù)據(jù)庫(kù)。這四種數(shù)據(jù)的存儲(chǔ)原理不盡相同，因而在應(yīng)用場(chǎng)景上也有些許的差異。一般常用的有作為數(shù)據(jù)緩存的redis和分布式系統(tǒng)的HBase。目前常見(jiàn)的數(shù)據(jù)庫(kù)排名可見(jiàn)網(wǎng)站：

https://db-engines.com/en/ranking

四種NoSQL的特點(diǎn)比較

關(guān)系型數(shù)據(jù)庫(kù)與非關(guān)系型數(shù)據(jù)庫(kù)本質(zhì)上的區(qū)別就在于存儲(chǔ)的數(shù)據(jù)是否具有一定的邏輯關(guān)系，由此產(chǎn)生的兩類數(shù)據(jù)庫(kù)看的性能和優(yōu)劣勢(shì)上也有一定的區(qū)別。二者對(duì)比可見(jiàn)下圖。

關(guān)系型數(shù)據(jù)庫(kù)與NoSQL的優(yōu)缺點(diǎn)對(duì)比

MySQL簡(jiǎn)介

介紹

在關(guān)系型數(shù)據(jù)庫(kù)中，MySQL可以說(shuō)是其中的王者。它是目前最流行的數(shù)據(jù)庫(kù)之一，由瑞典 MySQL AB 公司開(kāi)發(fā)，目前屬于 Oracle 公司。MySQL數(shù)據(jù)庫(kù)具有以下幾個(gè)方面的優(yōu)勢(shì)：

• 體積小、速度快；

• 代碼開(kāi)源，采用了 GPL 協(xié)議，可以修改源碼來(lái)開(kāi)發(fā)自己的 MySQL 系統(tǒng)；

• 支持大型的數(shù)據(jù)庫(kù)，可以處理?yè)碛猩锨f(wàn)條記錄的大型數(shù)據(jù)庫(kù)；

• 使用標(biāo)準(zhǔn)的 SQL 數(shù)據(jù)語(yǔ)言形式，并采用優(yōu)化的 SQL 查詢算法，有效地提高查詢速度；

• 使用 C 和 C++ 編寫(xiě)，并使用多種編譯器進(jìn)行測(cè)試，保證源代碼的可移植性；

• 可運(yùn)行在多個(gè)系統(tǒng)上，并且支持多種語(yǔ)言；

• 核心程序采用完全的多線程編程，可以靈活地為用戶提供服務(wù)，充分利用CPU資源。

邏輯架構(gòu)

MySQL的邏輯架構(gòu)可分為四層，包括連接層、服務(wù)層、引擎層和存儲(chǔ)層，各層的接口交互及作用如下圖所示。需要注意的是，由于本文將主要講解事務(wù)的實(shí)現(xiàn)原理，因此下文針對(duì)的都是InnoDB引擎下的情況。

連接層： 負(fù)責(zé)處理客戶端的連接以及權(quán)限的認(rèn)證。

服務(wù)層： 定義有許多不同的模塊，包括權(quán)限判斷，SQL接口，SQL解析，SQL分析優(yōu)化， 緩存查詢的處理以及部分內(nèi)置函數(shù)執(zhí)行等。MySQL的查詢語(yǔ)句在服務(wù)層內(nèi)進(jìn)行解析、優(yōu)化、緩存以及內(nèi)置函數(shù)的實(shí)現(xiàn)和存儲(chǔ)。

引擎層： 負(fù)責(zé)MySQL中數(shù)據(jù)的存儲(chǔ)和提取。MySQL中的服務(wù)器層不管理事務(wù)，事務(wù)是由存儲(chǔ)引擎實(shí)現(xiàn)的。其中使用最為廣泛的存儲(chǔ)引擎為InnoDB，其它的引擎都不支持事務(wù)。

存儲(chǔ)層： 負(fù)責(zé)將數(shù)據(jù)存儲(chǔ)與設(shè)備的文件系統(tǒng)中。

MySQL的邏輯架構(gòu)

MySQL事務(wù)

事務(wù)是MySQL區(qū)別于NoSQL的重要特征，是保證關(guān)系型數(shù)據(jù)庫(kù)數(shù)據(jù)一致性的關(guān)鍵技術(shù)。事務(wù)可看作是對(duì)數(shù)據(jù)庫(kù)操作的基本執(zhí)行單元，可能包含一個(gè)或者多個(gè)SQL語(yǔ)句。這些語(yǔ)句在執(zhí)行時(shí)，要么都執(zhí)行，要么都不執(zhí)行。

事務(wù)的執(zhí)行主要包括兩個(gè)操作，提交和回滾。

提交：commit，將事務(wù)執(zhí)行結(jié)果寫(xiě)入數(shù)據(jù)庫(kù)。

回滾：rollback，回滾所有已經(jīng)執(zhí)行的語(yǔ)句，返回修改之前的數(shù)據(jù)。

MySQL事務(wù)包含四個(gè)特性，號(hào)稱ACID四大天王。

原子性（Atomicity） ：語(yǔ)句要么全執(zhí)行，要么全不執(zhí)行，是事務(wù)最核心的特性，事務(wù)本身就是以原子性來(lái)定義的；實(shí)現(xiàn)主要基于undo log日志實(shí)現(xiàn)的。

持久性（Durability ?：保證事務(wù)提交后不會(huì)因?yàn)殄礄C(jī)等原因?qū)е聰?shù)據(jù)丟失；實(shí)現(xiàn)主要基于redo log日志。

隔離性（Isolation） ：保證事務(wù)執(zhí)行盡可能不受其他事務(wù)影響；InnoDB默認(rèn)的隔離級(jí)別是RR，RR的實(shí)現(xiàn)主要基于鎖機(jī)制、數(shù)據(jù)的隱藏列、undo log和類next-key lock機(jī)制。

一致性（Consistency） ：事務(wù)追求的最終目標(biāo)，一致性的實(shí)現(xiàn)既需要數(shù)據(jù)庫(kù)層面的保障，也需要應(yīng)用層面的保障。

原子性

事務(wù)的原子性就如原子操作一般，表示事務(wù)不可再分，其中的操作要么都做，要么都不做；如果事務(wù)中一個(gè)SQL語(yǔ)句執(zhí)行失敗，則已執(zhí)行的語(yǔ)句也必須回滾，數(shù)據(jù)庫(kù)退回到事務(wù)前的狀態(tài)。只有0和1，沒(méi)有其它值。

事務(wù)的原子性表明事務(wù)就是一個(gè)整體，當(dāng)事務(wù)無(wú)法成功執(zhí)行的時(shí)候，需要將事務(wù)中已經(jīng)執(zhí)行過(guò)的語(yǔ)句全部回滾，使得數(shù)據(jù)庫(kù)回歸到最初未開(kāi)始事務(wù)的狀態(tài)。

事務(wù)的原子性就是通過(guò)undo log日志進(jìn)行實(shí)現(xiàn)的。當(dāng)事務(wù)需要進(jìn)行回滾時(shí)，InnoDB引擎就會(huì)調(diào)用undo log日志進(jìn)行SQL語(yǔ)句的撤銷，實(shí)現(xiàn)數(shù)據(jù)的回滾。

持久性

事務(wù)的持久性是指當(dāng)事務(wù)提交之后，數(shù)據(jù)庫(kù)的改變就應(yīng)該是永久性的，而不是暫時(shí)的。這也就是說(shuō)，當(dāng)事務(wù)提交之后，任何其它操作甚至是系統(tǒng)的宕機(jī)故障都不會(huì)對(duì)原來(lái)事務(wù)的執(zhí)行結(jié)果產(chǎn)生影響。

事務(wù)的持久性是通過(guò)InnoDB存儲(chǔ)引擎中的redo log日志來(lái)實(shí)現(xiàn)的，具體實(shí)現(xiàn)思路見(jiàn)下文。

隔離性

原子性和持久性是單個(gè)事務(wù)本身層面的性質(zhì)，而隔離性是指事務(wù)之間應(yīng)該保持的關(guān)系。隔離性要求不同事務(wù)之間的影響是互不干擾的，一個(gè)事務(wù)的操作與其它事務(wù)是相互隔離的。

由于事務(wù)可能并不只包含一條SQL語(yǔ)句，所以在事務(wù)的執(zhí)行期間很有可能會(huì)有其它事務(wù)開(kāi)始執(zhí)行。因此多事務(wù)的并發(fā)性就要求事務(wù)之間的操作是相互隔離的。這一點(diǎn)跟多線程之間數(shù)據(jù)同步的概念有些類似。

鎖機(jī)制

事務(wù)之間的隔離，是通過(guò)鎖機(jī)制實(shí)現(xiàn)的。當(dāng)一個(gè)事務(wù)需要對(duì)數(shù)據(jù)庫(kù)中的某行數(shù)據(jù)進(jìn)行修改時(shí)，需要先給數(shù)據(jù)加鎖；加了鎖的數(shù)據(jù)，其它事務(wù)是不運(yùn)行操作的，只能等待當(dāng)前事務(wù)提交或回滾將鎖釋放。

鎖機(jī)制并不是一個(gè)陌生的概念，在許多場(chǎng)景中都會(huì)利用到不同實(shí)現(xiàn)的鎖對(duì)數(shù)據(jù)進(jìn)行保護(hù)和同步。而在MySQL中，根據(jù)不同的劃分標(biāo)準(zhǔn)，還可將鎖分為不同的種類。

按照粒度劃分：行鎖、表鎖、頁(yè)鎖

按照使用方式劃分：共享鎖、排它鎖

按照思想劃分：悲觀鎖、樂(lè)觀鎖

鎖機(jī)制的知識(shí)點(diǎn)很多，由于篇幅不好全部展開(kāi)講。這里對(duì)按照粒度劃分的鎖進(jìn)行簡(jiǎn)單介紹。

粒度：指數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)單位中保存數(shù)據(jù)的細(xì)化或綜合程度的級(jí)別。細(xì)化程度越高，粒度級(jí)就越小；相反，細(xì)化程度越低，粒度級(jí)就越大。

MySQL按照鎖的粒度劃分可以分為行鎖、表鎖和頁(yè)鎖。

行鎖：粒度最小的鎖，表示只針對(duì)當(dāng)前操作的行進(jìn)行加鎖；

表鎖：粒度最大的鎖，表示當(dāng)前的操作對(duì)整張表加鎖；

頁(yè)鎖：粒度介于行級(jí)鎖和表級(jí)鎖中間的一種鎖，表示對(duì)頁(yè)進(jìn)行加鎖。

數(shù)據(jù)庫(kù)的粒度劃分

這三種鎖是在不同層次上對(duì)數(shù)據(jù)進(jìn)行鎖定，由于粒度的不同，其帶來(lái)的好處和劣勢(shì)也不一而同。

表鎖在操作數(shù)據(jù)時(shí)會(huì)鎖定整張表，因而并發(fā)性能較差；

行鎖則只鎖定需要操作的數(shù)據(jù)，并發(fā)性能好。但是由于加鎖本身需要消耗資源(獲得鎖、檢查鎖、釋放鎖等都需要消耗資源)，因此在鎖定數(shù)據(jù)較多情況下使用表鎖可以節(jié)省大量資源。

MySQL中不同的存儲(chǔ)引擎能夠支持的鎖也是不一樣的。MyIsam只支持表鎖，而InnoDB同時(shí)支持表鎖和行鎖，且出于性能考慮，絕大多數(shù)情況下使用的都是行鎖。

并發(fā)讀寫(xiě)問(wèn)題

在并發(fā)情況下，MySQL的同時(shí)讀寫(xiě)可能會(huì)導(dǎo)致三類問(wèn)題，臟讀、不可重復(fù)度和幻讀。

（1）臟讀：當(dāng)前事務(wù)中讀到其他事務(wù)未提交的數(shù)據(jù)，也就是臟數(shù)據(jù)。

以上圖為例，事務(wù)A在讀取文章的閱讀量時(shí)，讀取到了事務(wù)B為提交的數(shù)據(jù)。如果事務(wù)B最后沒(méi)有順利提交，導(dǎo)致事務(wù)回滾，那么實(shí)際上閱讀量并沒(méi)有修改成功，而事務(wù)A卻是讀到的修改后的值，顯然不合情理。

（2）不可重復(fù)讀：在事務(wù)A中先后兩次讀取同一個(gè)數(shù)據(jù)，但是兩次讀取的結(jié)果不一樣。臟讀與不可重復(fù)讀的區(qū)別在于：前者讀到的是其他事務(wù)未提交的數(shù)據(jù)，后者讀到的是其他事務(wù)已提交的數(shù)據(jù)。

以上圖為例，事務(wù)A在先后讀取文章閱讀量的數(shù)據(jù)時(shí)，結(jié)果卻不一樣。說(shuō)明事務(wù)A在執(zhí)行的過(guò)程中，閱讀量的值被其它事務(wù)給修改了。這樣使得數(shù)據(jù)的查詢結(jié)果不再可靠，同樣也不合實(shí)際。

（3）幻讀：在事務(wù)A中按照某個(gè)條件先后兩次查詢數(shù)據(jù)庫(kù)，兩次查詢結(jié)果的行數(shù)不同，這種現(xiàn)象稱為幻讀。不可重復(fù)讀與幻讀的區(qū)別可以通俗的理解為：前者是數(shù)據(jù)變了，后者是數(shù)據(jù)的行數(shù)變了。

以上圖為例，當(dāng)對(duì)0<閱讀量<100的文章進(jìn)行查詢時(shí)，先查到了一個(gè)結(jié)果，后來(lái)查詢到了兩個(gè)結(jié)果。這表明同一個(gè)事務(wù)的查詢結(jié)果數(shù)不一，行數(shù)不一致。這樣的問(wèn)題使得在根據(jù)某些條件對(duì)數(shù)據(jù)篩選的時(shí)候，前后篩選結(jié)果不具有可靠性。

隔離級(jí)別

根據(jù)上面這三種問(wèn)題，產(chǎn)生了四種隔離級(jí)別，表明數(shù)據(jù)庫(kù)不同程度的隔離性質(zhì)。

在實(shí)際的數(shù)據(jù)庫(kù)設(shè)計(jì)中，隔離級(jí)別越高，導(dǎo)致數(shù)據(jù)庫(kù)的并發(fā)效率會(huì)越低；而隔離級(jí)別太低，又會(huì)導(dǎo)致數(shù)據(jù)庫(kù)在讀寫(xiě)過(guò)程中會(huì)遇到各種亂七八糟的問(wèn)題。

因此在大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)中，默認(rèn)的隔離級(jí)別時(shí)讀已提交（如Oracle）或者可重復(fù)讀RR（MySQL的InnoDB引擎）。

MVCC

又是一個(gè)難嚼的大塊頭。MVCC就是用來(lái)實(shí)現(xiàn)上面的第三個(gè)隔離級(jí)別，可重復(fù)讀RR。

MVCC：Multi-Version Concurrency Control，即多版本的并發(fā)控制協(xié)議。

MVCC的特點(diǎn)就是在同一時(shí)刻，不同事務(wù)可以讀取到不同版本的數(shù)據(jù)，從而可以解決臟讀和不可重復(fù)讀的問(wèn)題。

MVCC實(shí)際上就是通過(guò)數(shù)據(jù)的隱藏列和回滾日志（undo log），實(shí)現(xiàn)多個(gè)版本數(shù)據(jù)的共存。這樣的好處是，使用MVCC進(jìn)行讀數(shù)據(jù)的時(shí)候，不用加鎖，從而避免了同時(shí)讀寫(xiě)的沖突。

在實(shí)現(xiàn)MVCC時(shí)，每一行的數(shù)據(jù)中會(huì)額外保存幾個(gè)隱藏的列，比如當(dāng)前行創(chuàng)建時(shí)的版本號(hào)和刪除時(shí)間和指向undo log的回滾指針。這里的版本號(hào)并不是實(shí)際的時(shí)間值，而是系統(tǒng)版本號(hào)。每開(kāi)始新的事務(wù)，系統(tǒng)版本號(hào)都會(huì)自動(dòng)遞增。事務(wù)開(kāi)始時(shí)的系統(tǒng)版本號(hào)會(huì)作為事務(wù)的版本號(hào)，用來(lái)和查詢每行記錄的版本號(hào)進(jìn)行比較。

每個(gè)事務(wù)又有自己的版本號(hào)，這樣事務(wù)內(nèi)執(zhí)行數(shù)據(jù)操作時(shí)，就通過(guò)版本號(hào)的比較來(lái)達(dá)到數(shù)據(jù)版本控制的目的。

另外，InnoDB實(shí)現(xiàn)的隔離級(jí)別RR時(shí)可以避免幻讀現(xiàn)象的，這是通過(guò)next-key lock機(jī)制實(shí)現(xiàn)的。

next-key lock實(shí)際上就是行鎖的一種，只不過(guò)它不只是會(huì)鎖住當(dāng)前行記錄的本身，還會(huì)鎖定一個(gè)范圍。比如上面幻讀的例子，開(kāi)始查詢0<閱讀量<100的文章時(shí)，只查到了一個(gè)結(jié)果。next-key lock會(huì)將查詢出的這一行進(jìn)行鎖定，同時(shí)還會(huì)對(duì)0<閱讀量<100這個(gè)范圍進(jìn)行加鎖，這實(shí)際上是一種間隙鎖。間隙鎖能夠防止其他事務(wù)在這個(gè)間隙修改或者插入記錄。這樣一來(lái)，就保證了在0<閱讀量<100這個(gè)間隙中，只存在原來(lái)的一行數(shù)據(jù)，從而避免了幻讀。

間隙鎖：封鎖索引記錄中的間隔

雖然InnoDB使用next-key lock能夠避免幻讀問(wèn)題，但卻并不是真正的可串行化隔離。再來(lái)看一個(gè)例子吧。

首先提一個(gè)問(wèn)題：

在T6時(shí)間，事務(wù)A提交事務(wù)之后，猜一猜文章A和文章B的閱讀量為多少？

答案是，文章AB的閱讀量都被修改成了10000。這代表著事務(wù)B的提交實(shí)際上對(duì)事務(wù)A的執(zhí)行產(chǎn)生了影響，表明兩個(gè)事務(wù)之間并不是完全隔離的。雖然能夠避免幻讀現(xiàn)象，但是卻沒(méi)有達(dá)到可串行化的級(jí)別。

這還說(shuō)明，避免臟讀、不可重復(fù)讀和幻讀，是達(dá)到可串行化的隔離級(jí)別的必要不充分條件。可串行化是都能夠避免臟讀、不可重復(fù)讀和幻讀，但是避免臟讀、不可重復(fù)讀和幻讀卻不一定達(dá)到了可串行化。

一致性

一致性是指事務(wù)執(zhí)行結(jié)束后，數(shù)據(jù)庫(kù)的完整性約束沒(méi)有被破壞，事務(wù)執(zhí)行的前后都是合法的數(shù)據(jù)狀態(tài)。

一致性是事務(wù)追求的最終目標(biāo)，原子性、持久性和隔離性，實(shí)際上都是為了保證數(shù)據(jù)庫(kù)狀態(tài)的一致性而存在的。

這就不多說(shuō)了吧。你細(xì)品。

MySQL日志系統(tǒng)

了解完MySQL的基本架構(gòu)，大體上能夠?qū)ySQL的執(zhí)行流程有了比較清晰的認(rèn)知。接下來(lái)我將為大家介紹一下日志系統(tǒng)。

MySQL日志系統(tǒng)是數(shù)據(jù)庫(kù)的重要組件，用于記錄數(shù)據(jù)庫(kù)的更新和修改。若數(shù)據(jù)庫(kù)發(fā)生故障，可通過(guò)不同日志記錄恢復(fù)數(shù)據(jù)庫(kù)的原來(lái)數(shù)據(jù)。因此實(shí)際上日志系統(tǒng)直接決定著MySQL運(yùn)行的魯棒性和穩(wěn)健性。

MySQL的日志有很多種，如二進(jìn)制日志（binlog）、錯(cuò)誤日志、查詢?nèi)罩尽⒙樵內(nèi)罩镜?#xff0c;此外InnoDB存儲(chǔ)引擎還提供了兩種日志：redo log（重做日志）和undo log（回滾日志）。這里將重點(diǎn)針對(duì)InnoDB引擎，對(duì)重做日志、回滾日志和二進(jìn)制日志這三種進(jìn)行分析。

重做日志（redo log）

重做日志（redo log）是InnoDB引擎層的日志，用來(lái)記錄事務(wù)操作引起數(shù)據(jù)的變化，記錄的是數(shù)據(jù)頁(yè)的物理修改。

重做日記的作用其實(shí)很好理解，我打個(gè)比方。數(shù)據(jù)庫(kù)中數(shù)據(jù)的修改就好比你寫(xiě)的論文，萬(wàn)一哪天論文丟了怎么呢？以防這種不幸的發(fā)生，我們可以在寫(xiě)論文的時(shí)候，每一次修改都拿個(gè)小本本記錄一下，記錄什么時(shí)間對(duì)某一頁(yè)進(jìn)行了怎么樣的修改。這就是重做日志。

InnoDB引擎對(duì)數(shù)據(jù)的更新，是先將更新記錄寫(xiě)入redo log日志，然后會(huì)在系統(tǒng)空閑的時(shí)候或者是按照設(shè)定的更新策略再將日志中的內(nèi)容更新到磁盤(pán)之中。這就是所謂的預(yù)寫(xiě)式技術(shù)（Write Ahead logging）。這種技術(shù)可以大大減少I(mǎi)O操作的頻率，提升數(shù)據(jù)刷新的效率。

臟數(shù)據(jù)刷盤(pán)

值得注意的是，redo log日志的大小是固定的，為了能夠持續(xù)不斷的對(duì)更新記錄進(jìn)行寫(xiě)入，在redo log日志中設(shè)置了兩個(gè)標(biāo)志位置，checkpoint和write_pos，分別表示記錄擦除的位置和記錄寫(xiě)入的位置。redo log日志的數(shù)據(jù)寫(xiě)入示意圖可見(jiàn)下圖。

當(dāng)write_pos標(biāo)志到了日志結(jié)尾時(shí)，會(huì)從結(jié)尾跳至日志頭部進(jìn)行重新循環(huán)寫(xiě)入。所以redo log的邏輯結(jié)構(gòu)并不是線性的，而是可看作一個(gè)圓周運(yùn)動(dòng)。write_pos與checkpoint中間的空間可用于寫(xiě)入新數(shù)據(jù)，寫(xiě)入和擦除都是往后推移，循環(huán)往復(fù)的。

當(dāng)write_pos追上checkpoint時(shí)，表示redo log日志已經(jīng)寫(xiě)滿。這時(shí)不能繼續(xù)執(zhí)行新的數(shù)據(jù)庫(kù)更新語(yǔ)句，需要停下來(lái)先刪除一些記錄，執(zhí)行checkpoint規(guī)則騰出可寫(xiě)空間。

checkpoint規(guī)則：checkpoint觸發(fā)后，將buffer中臟數(shù)據(jù)頁(yè)和臟日志頁(yè)都刷到磁盤(pán)。

臟數(shù)據(jù)：指內(nèi)存中未刷到磁盤(pán)的數(shù)據(jù)。

redo log中最重要的概念就是緩沖池buffer pool，這是在內(nèi)存中分配的一個(gè)區(qū)域，包含了磁盤(pán)中部分?jǐn)?shù)據(jù)頁(yè)的映射，作為訪問(wèn)數(shù)據(jù)庫(kù)的緩沖。

當(dāng)請(qǐng)求讀取數(shù)據(jù)時(shí)，會(huì)先判斷是否在緩沖池命中，如果未命中才會(huì)在磁盤(pán)上進(jìn)行檢索后放入緩沖池；

當(dāng)請(qǐng)求寫(xiě)入數(shù)據(jù)時(shí)，會(huì)先寫(xiě)入緩沖池，緩沖池中修改的數(shù)據(jù)會(huì)定期刷新到磁盤(pán)中。這一過(guò)程也被稱之為刷臟 。

因此，當(dāng)數(shù)據(jù)修改時(shí)，除了修改buffer pool中的數(shù)據(jù)，還會(huì)在redo log中記錄這次操作；當(dāng)事務(wù)提交時(shí)，會(huì)根據(jù)redo log的記錄對(duì)數(shù)據(jù)進(jìn)行刷盤(pán)。如果MySQL宕機(jī)，重啟時(shí)可以讀取redo log中的數(shù)據(jù)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行恢復(fù)，從而保證了事務(wù)的持久性，使得數(shù)據(jù)庫(kù)獲得crash-safe能力。

臟日志刷盤(pán)

除了上面提到的對(duì)于臟數(shù)據(jù)的刷盤(pán)，實(shí)際上redo log日志在記錄時(shí)，為了保證日志文件的持久化，也需要經(jīng)歷將日志記錄從內(nèi)存寫(xiě)入到磁盤(pán)的過(guò)程。redo log日志可分為兩個(gè)部分，一是存在易失性內(nèi)存中的緩存日志redo log buff，二是保存在磁盤(pán)上的redo log日志文件redo log file。

為了確保每次記錄都能夠?qū)懭氲酱疟P(pán)中的日志中，每次將redo log buffer中的日志寫(xiě)入redo log file的過(guò)程中都會(huì)調(diào)用一次操作系統(tǒng)的fsync操作。

fsync函數(shù)：包含在UNIX系統(tǒng)頭文件#include <unistd.h>中，用于同步內(nèi)存中所有已修改的文件數(shù)據(jù)到儲(chǔ)存設(shè)備。

在寫(xiě)入的過(guò)程中，還需要經(jīng)過(guò)操作系統(tǒng)內(nèi)核空間的os buffer。redo log日志的寫(xiě)入過(guò)程可見(jiàn)下圖。

redo log日志刷盤(pán)流程

二進(jìn)制日志（binlog）

二進(jìn)制日志binlog是服務(wù)層的日志，還被稱為歸檔日志。binlog主要記錄數(shù)據(jù)庫(kù)的變化情況，內(nèi)容包括數(shù)據(jù)庫(kù)所有的更新操作。所有涉及數(shù)據(jù)變動(dòng)的操作，都要記錄進(jìn)二進(jìn)制日志中。因此有了binlog可以很方便的對(duì)數(shù)據(jù)進(jìn)行復(fù)制和備份，因而也常用作主從庫(kù)的同步。

這里binlog所存儲(chǔ)的內(nèi)容看起來(lái)似乎與redo log很相似，但是其實(shí)不然。redo log是一種物理日志，記錄的是實(shí)際上對(duì)某個(gè)數(shù)據(jù)進(jìn)行了怎么樣的修改；而binlog是邏輯日志，記錄的是SQL語(yǔ)句的原始邏輯，比如”給ID=2這一行的a字段加1 "。binlog日志中的內(nèi)容是二進(jìn)制的，根據(jù)日記格式參數(shù)的不同，可能基于SQL語(yǔ)句、基于數(shù)據(jù)本身或者二者的混合。一般常用記錄的都是SQL語(yǔ)句。

這里的物理和邏輯的概念，我的個(gè)人理解是：

物理的日志可看作是實(shí)際數(shù)據(jù)庫(kù)中數(shù)據(jù)頁(yè)上的變化信息，只看重結(jié)果，而不在乎是通過(guò)“何種途徑”導(dǎo)致了這種結(jié)果；

邏輯的日志可看作是通過(guò)了某一種方法或者操作手段導(dǎo)致數(shù)據(jù)發(fā)生了變化，存儲(chǔ)的是邏輯性的操作。

同時(shí)，redo log是基于crash recovery，保證MySQL宕機(jī)后的數(shù)據(jù)恢復(fù)；而binlog是基于point-in-time recovery，保證服務(wù)器可以基于時(shí)間點(diǎn)對(duì)數(shù)據(jù)進(jìn)行恢復(fù)，或者對(duì)數(shù)據(jù)進(jìn)行備份。

事實(shí)上最開(kāi)始MySQL是沒(méi)有redo log日志的。因?yàn)槠鹣萂ySQL是沒(méi)有InnoDB引擎的，自帶的引擎是MyISAM。binlog是服務(wù)層的日志，因此所有引擎都能夠使用。但是光靠binlog日志只能提供歸檔的作用，無(wú)法提供crash-safe能力，所以InnoDB引擎就采用了學(xué)自于Oracle的技術(shù)，也就是redo log，這才擁有了crash-safe能力。這里對(duì)redo log日志和binlog日志的特點(diǎn)分別進(jìn)行了對(duì)比：

redo log與binlog的特點(diǎn)比較

在MySQL執(zhí)行更新語(yǔ)句時(shí)，都會(huì)涉及到redo log日志和binlog日志的讀寫(xiě)。一條更新語(yǔ)句的執(zhí)行過(guò)程如下：

MySQL更新語(yǔ)句的執(zhí)行過(guò)程

從上圖可以看出，MySQL在執(zhí)行更新語(yǔ)句的時(shí)候，在服務(wù)層進(jìn)行語(yǔ)句的解析和執(zhí)行，在引擎層進(jìn)行數(shù)據(jù)的提取和存儲(chǔ)；同時(shí)在服務(wù)層對(duì)binlog進(jìn)行寫(xiě)入，在InnoDB內(nèi)進(jìn)行redo log的寫(xiě)入。

不僅如此，在對(duì)redo log寫(xiě)入時(shí)有兩個(gè)階段的提交，一是binlog寫(xiě)入之前prepare狀態(tài)的寫(xiě)入，二是binlog寫(xiě)入之后commit狀態(tài)的寫(xiě)入。

之所以要安排這么一個(gè)兩階段提交，自然是有它的道理的。現(xiàn)在我們可以假設(shè)不采用兩階段提交的方式，而是采用“單階段”進(jìn)行提交，即要么先寫(xiě)入redo log，后寫(xiě)入binlog；要么先寫(xiě)入binlog，后寫(xiě)入redo log。這兩種方式的提交都會(huì)導(dǎo)致原先數(shù)據(jù)庫(kù)的狀態(tài)和被恢復(fù)后的數(shù)據(jù)庫(kù)的狀態(tài)不一致。

先寫(xiě)入redo log，后寫(xiě)入binlog：

在寫(xiě)完redo log之后，數(shù)據(jù)此時(shí)具有crash-safe能力，因此系統(tǒng)崩潰，數(shù)據(jù)會(huì)恢復(fù)成事務(wù)開(kāi)始之前的狀態(tài)。但是，若在redo log寫(xiě)完時(shí)候，binlog寫(xiě)入之前，系統(tǒng)發(fā)生了宕機(jī)。此時(shí)binlog沒(méi)有對(duì)上面的更新語(yǔ)句進(jìn)行保存，導(dǎo)致當(dāng)使用binlog進(jìn)行數(shù)據(jù)庫(kù)的備份或者恢復(fù)時(shí)，就少了上述的更新語(yǔ)句。從而使得id=2這一行的數(shù)據(jù)沒(méi)有被更新。

先寫(xiě)redo log后寫(xiě)binlog的問(wèn)題

先寫(xiě)入binlog，后寫(xiě)入redo log：

寫(xiě)完binlog之后，所有的語(yǔ)句都被保存，所以通過(guò)binlog復(fù)制或恢復(fù)出來(lái)的數(shù)據(jù)庫(kù)中id=2這一行的數(shù)據(jù)會(huì)被更新為a=1。但是如果在redo log寫(xiě)入之前，系統(tǒng)崩潰，那么redo log中記錄的這個(gè)事務(wù)會(huì)無(wú)效，導(dǎo)致實(shí)際數(shù)據(jù)庫(kù)中id=2這一行的數(shù)據(jù)并沒(méi)有更新。

先寫(xiě)binlog后寫(xiě)redo?log的問(wèn)題

由此可見(jiàn)，兩階段的提交就是為了避免上述的問(wèn)題，使得binlog和redo log中保存的信息是一致的。

回滾日志（undo log）

回滾日志同樣也是InnoDB引擎提供的日志，顧名思義，回滾日志的作用就是對(duì)數(shù)據(jù)進(jìn)行回滾。當(dāng)事務(wù)對(duì)數(shù)據(jù)庫(kù)進(jìn)行修改，InnoDB引擎不僅會(huì)記錄redo log，還會(huì)生成對(duì)應(yīng)的undo log日志；如果事務(wù)執(zhí)行失敗或調(diào)用了rollback，導(dǎo)致事務(wù)需要回滾，就可以利用undo log中的信息將數(shù)據(jù)回滾到修改之前的樣子。

但是undo log不redo log不一樣，它屬于邏輯日志。它對(duì)SQL語(yǔ)句執(zhí)行相關(guān)的信息進(jìn)行記錄。當(dāng)發(fā)生回滾時(shí)，InnoDB引擎會(huì)根據(jù)undo log日志中的記錄做與之前相反的工作。比如對(duì)于每個(gè)數(shù)據(jù)插入操作（insert），回滾時(shí)會(huì)執(zhí)行數(shù)據(jù)刪除操作（delete）；對(duì)于每個(gè)數(shù)據(jù)刪除操作（delete），回滾時(shí)會(huì)執(zhí)行數(shù)據(jù)插入操作（insert）；對(duì)于每個(gè)數(shù)據(jù)更新操作（update），回滾時(shí)會(huì)執(zhí)行一個(gè)相反的數(shù)據(jù)更新操作（update），把數(shù)據(jù)改回去。undo log由兩個(gè)作用，一是提供回滾，二是實(shí)現(xiàn)MVCC。

主從復(fù)制

主從復(fù)制的概念很簡(jiǎn)單，就是從原來(lái)的數(shù)據(jù)庫(kù)復(fù)制一個(gè)完全一樣的數(shù)據(jù)庫(kù)，原來(lái)的數(shù)據(jù)庫(kù)稱作主數(shù)據(jù)庫(kù)，復(fù)制的數(shù)據(jù)庫(kù)稱為從數(shù)據(jù)庫(kù)。從數(shù)據(jù)庫(kù)會(huì)與主數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)同步，保持二者的數(shù)據(jù)一致性。

主從復(fù)制的原理實(shí)際上就是通過(guò)bin log日志實(shí)現(xiàn)的。bin log日志中保存了數(shù)據(jù)庫(kù)中所有SQL語(yǔ)句，通過(guò)對(duì)bin log日志中SQL的復(fù)制，然后再進(jìn)行語(yǔ)句的執(zhí)行即可實(shí)現(xiàn)從數(shù)據(jù)庫(kù)與主數(shù)據(jù)庫(kù)的同步。

主從復(fù)制的過(guò)程可見(jiàn)下圖。主從復(fù)制的過(guò)程主要是靠三個(gè)線程進(jìn)行的，一個(gè)運(yùn)行在主服務(wù)器中的發(fā)送線程，用于發(fā)送binlog日志到從服務(wù)器。兩外兩個(gè)運(yùn)行在從服務(wù)器上的I/O線程和SQL線程。I/O線程用于讀取主服務(wù)器發(fā)送過(guò)來(lái)的binlog日志內(nèi)容，并拷貝到本地的中繼日志中。SQL線程用于讀取中繼日志中關(guān)于數(shù)據(jù)更新的SQL語(yǔ)句并執(zhí)行，從而實(shí)現(xiàn)主從庫(kù)的數(shù)據(jù)一致。

主從復(fù)制原理

之所以需要實(shí)現(xiàn)主從復(fù)制，實(shí)際上是由實(shí)際應(yīng)用場(chǎng)景所決定的。主從復(fù)制能夠帶來(lái)的好處有：

1. 通過(guò)復(fù)制實(shí)現(xiàn)數(shù)據(jù)的異地備份，當(dāng)主數(shù)據(jù)庫(kù)故障時(shí)，可切換從數(shù)據(jù)庫(kù)，避免數(shù)據(jù)丟失。

2. 可實(shí)現(xiàn)架構(gòu)的擴(kuò)展，當(dāng)業(yè)務(wù)量越來(lái)越大，I/O訪問(wèn)頻率過(guò)高時(shí)，采用多庫(kù)的存儲(chǔ)，可以降低磁盤(pán)I/O訪問(wèn)的頻率，提高單個(gè)機(jī)器的I/O性能。

3. 可實(shí)現(xiàn)讀寫(xiě)分離，使數(shù)據(jù)庫(kù)能支持更大的并發(fā)。

4. 實(shí)現(xiàn)服務(wù)器的負(fù)載均衡，通過(guò)在主服務(wù)器和從服務(wù)器之間切分處理客戶查詢的負(fù)荷。

總結(jié)

MySQL數(shù)據(jù)庫(kù)應(yīng)該算是程序員必須掌握的技術(shù)之一了。無(wú)論是項(xiàng)目過(guò)程中還是面試中，MySQL都是非常重要的基礎(chǔ)知識(shí)。不過(guò)，對(duì)于MySQL來(lái)說(shuō)，真的東西太多了。我在寫(xiě)這篇文章的時(shí)候，查閱了大量的資料，發(fā)現(xiàn)越看不懂的越多。還真是應(yīng)了那句話：

你知道的越多，不知道的也就越多。

這篇文章著重是從理論的角度去解析MySQL基本的事務(wù)和日志系統(tǒng)的基本原理，我在表述的時(shí)候盡可能的避免采用實(shí)際的代碼去描述。即便是這篇將近一萬(wàn)字+近二十副純手工繪制的圖解，也難以將MySQL的博大精深分析透徹。

但是我相信，對(duì)于初學(xué)者而言，這些理論能夠讓你對(duì)MySQL有一個(gè)整體的感知，讓你對(duì)“何謂關(guān)系型數(shù)據(jù)庫(kù)”這么一個(gè)問(wèn)題有了比較清晰的認(rèn)知；而對(duì)于熟練掌握MySQL的大佬來(lái)說(shuō)，或許本文也能夠喚醒你塵封已久的底層理論基礎(chǔ)，對(duì)你之后的面試也會(huì)有一定幫助。

技術(shù)這種東西沒(méi)有絕對(duì)的對(duì)錯(cuò)，倘若文中有誤還請(qǐng)諒解，并歡迎與我討論。自主思考永遠(yuǎn)比被動(dòng)接受更有效。

Reference

• https://www.cnblogs.com/kismetv/p/10331633.html

• https://www.cnblogs.com/ivy-zheng/p/11094528.html

• https://blog.csdn.net/qq_39016934/article/details/90116706

• https://www.jianshu.com/p/5af73b203f2a

• https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html#auto_id_2

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的超干货！为了让你彻底弄懂MySQL事务日志，我通宵肝出了这份图解！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。