前言

在前一陣子，大哥問過我：”你知道MySQL的原子性是怎么保證的嗎“。我懵逼了，MySQL怎么保證原子性？我不會(huì)啊。

誰都知道在事務(wù)里邊原子性的意思：”一個(gè)事務(wù)包含多個(gè)操作，這些操作要么全部執(zhí)行，要么全都不執(zhí)行“

于是大哥就給我講：”用的就是 undo log 啊“。

我：”臥槽，又是知識(shí)盲區(qū)“

后來在網(wǎng)上翻了一下，MySQL里邊還有幾種常見的log，分別為：

• undo log

• binlog

• redo log

如果你也未曾關(guān)注過這些log，麻煩在評(píng)論區(qū)給我留個(gè)言，讓我覺得不是只有我一個(gè)人這么菜，行不行？

后來我又去搜了一下，其實(shí)這幾種log在面試的時(shí)候也經(jīng)常會(huì)問到，這篇文章以最簡單的方式來講講，希望對(duì)大家有幫助。

一、什么是binlog

binlog其實(shí)在日常的開發(fā)中是聽得很多的，因?yàn)楹芏鄷r(shí)候數(shù)據(jù)的更新就依賴著binlog。

舉個(gè)很簡單的例子：我們的數(shù)據(jù)是保存在數(shù)據(jù)庫里邊的嘛，現(xiàn)在我們對(duì)某個(gè)商品的某個(gè)字段的內(nèi)容改了（數(shù)據(jù)庫變更），而用戶檢索的出來數(shù)據(jù)是走搜索引擎的。為了讓用戶能搜到最新的數(shù)據(jù)，我們需要把引擎的數(shù)據(jù)也改掉。

一句話：數(shù)據(jù)庫的變更，搜索引擎的數(shù)據(jù)也需要變更。

于是，我們就會(huì)監(jiān)聽binlog的變更，如果binlog有變更了，那我們就需要將變更寫到對(duì)應(yīng)的數(shù)據(jù)源。

什么是binlog？

binlog記錄了數(shù)據(jù)庫表結(jié)構(gòu)和表數(shù)據(jù)變更，比如update/delete/insert/truncate/create。它不會(huì)記錄select（因?yàn)檫@沒有對(duì)表沒有進(jìn)行變更）

binlog長什么樣？

binlog我們可以簡單理解為：存儲(chǔ)著每條變更的SQL語句（當(dāng)然從下面的圖看來看，不止SQL，還有XID「事務(wù)Id」等等）

binlog一般用來做什么

主要有兩個(gè)作用：復(fù)制和恢復(fù)數(shù)據(jù)

• MySQL在公司使用的時(shí)候往往都是一主多從結(jié)構(gòu)的，從服務(wù)器需要與主服務(wù)器的數(shù)據(jù)保持一致，這就是通過binlog來實(shí)現(xiàn)的

• 數(shù)據(jù)庫的數(shù)據(jù)被干掉了，我們可以通過binlog來對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。

因?yàn)閎inlog記錄了數(shù)據(jù)庫表的變更，所以我們可以用binlog進(jìn)行復(fù)制（主從復(fù)制)和恢復(fù)數(shù)據(jù)。

二、什么是redo log

假設(shè)我們有一條sql語句：

update?user_table?set?name='java3y'?where?id?=?'3'

MySQL執(zhí)行這條SQL語句，肯定是先把id=3的這條記錄查出來，然后將name字段給改掉。這沒問題吧？

實(shí)際上Mysql的基本存儲(chǔ)結(jié)構(gòu)是頁(記錄都存在頁里邊)，所以MySQL是先把這條記錄所在的頁找到，然后把該頁加載到內(nèi)存中，將對(duì)應(yīng)記錄進(jìn)行修改。

現(xiàn)在就可能存在一個(gè)問題：如果在內(nèi)存中把數(shù)據(jù)改了，還沒來得及落磁盤，而此時(shí)的數(shù)據(jù)庫掛了怎么辦？顯然這次更改就丟了。

如果每個(gè)請(qǐng)求都需要將數(shù)據(jù)立馬落磁盤之后，那速度會(huì)很慢，MySQL可能也頂不住。所以MySQL是怎么做的呢？

MySQL引入了redo log，內(nèi)存寫完了，然后會(huì)寫一份redo log，這份redo log記載著這次在某個(gè)頁上做了什么修改。

其實(shí)寫redo log的時(shí)候，也會(huì)有buffer，是先寫buffer，再真正落到磁盤中的。至于從buffer什么時(shí)候落磁盤，會(huì)有配置供我們配置。

寫redo log也是需要寫磁盤的，但它的好處就是順序IO（我們都知道順序IO比隨機(jī)IO快非常多）。

所以，redo log的存在為了：當(dāng)我們修改的時(shí)候，寫完內(nèi)存了，但數(shù)據(jù)還沒真正寫到磁盤的時(shí)候。此時(shí)我們的數(shù)據(jù)庫掛了，我們可以根據(jù)redo log來對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。因?yàn)閞edo log是順序IO，所以寫入的速度很快，并且redo log記載的是物理變化（xxxx頁做了xxx修改），文件的體積很小，恢復(fù)速度很快。

三、binlog和redo log

看到這里，你可能會(huì)想：binlog和redo log 這倆也太像了吧，都是用作”恢復(fù)“的。

其實(shí)他倆除了"恢復(fù)"這塊是相似的，很多都不一樣，下面看我列一下。

存儲(chǔ)的內(nèi)容

binlog記載的是update/delete/insert這樣的SQL語句，而redo log記載的是物理修改的內(nèi)容（xxxx頁修改了xxx）。

所以在搜索資料的時(shí)候會(huì)有這樣的說法：redo log 記錄的是數(shù)據(jù)的物理變化，binlog 記錄的是數(shù)據(jù)的邏輯變化

功能

redo log的作用是為持久化而生的。寫完內(nèi)存，如果數(shù)據(jù)庫掛了，那我們可以通過redo log來恢復(fù)內(nèi)存還沒來得及刷到磁盤的數(shù)據(jù)，將redo log加載到內(nèi)存里邊，那內(nèi)存就能恢復(fù)到掛掉之前的數(shù)據(jù)了。

binlog的作用是復(fù)制和恢復(fù)而生的。

• 主從服務(wù)器需要保持?jǐn)?shù)據(jù)的一致性，通過binlog來同步數(shù)據(jù)。

• 如果整個(gè)數(shù)據(jù)庫的數(shù)據(jù)都被刪除了，binlog存儲(chǔ)著所有的數(shù)據(jù)變更情況，那么可以通過binlog來對(duì)數(shù)據(jù)進(jìn)行恢復(fù)。

又看到這里，你會(huì)想：”如果整個(gè)數(shù)據(jù)庫的數(shù)據(jù)都被刪除了，那我可以用redo log的記錄來恢復(fù)嗎？“不能

因?yàn)楣δ艿牟煌?#xff0c;redo log 存儲(chǔ)的是物理數(shù)據(jù)的變更，如果我們內(nèi)存的數(shù)據(jù)已經(jīng)刷到了磁盤了，那redo log的數(shù)據(jù)就無效了。所以redo log不會(huì)存儲(chǔ)著歷史所有數(shù)據(jù)的變更，文件的內(nèi)容會(huì)被覆蓋的。

binlog和redo log 寫入的細(xì)節(jié)

redo log是MySQL的InnoDB引擎所產(chǎn)生的。

binlog無論MySQL用什么引擎，都會(huì)有的。

InnoDB是有事務(wù)的，事務(wù)的四大特性之一：持久性就是靠redo log來實(shí)現(xiàn)的（如果寫入內(nèi)存成功，但數(shù)據(jù)還沒真正刷到磁盤，如果此時(shí)的數(shù)據(jù)庫掛了，我們可以靠redo log來恢復(fù)內(nèi)存的數(shù)據(jù)，這就實(shí)現(xiàn)了持久性）。

上面也提到，在修改的數(shù)據(jù)的時(shí)候，binlog會(huì)記載著變更的類容，redo log也會(huì)記載著變更的內(nèi)容。（只不過一個(gè)存儲(chǔ)的是物理變化，一個(gè)存儲(chǔ)的是邏輯變化）。那他們的寫入順序是什么樣的呢？

redo log事務(wù)開始的時(shí)候，就開始記錄每次的變更信息，而binlog是在事務(wù)提交的時(shí)候才記錄。

于是新有的問題又出現(xiàn)了：我寫其中的某一個(gè)log，失敗了，那會(huì)怎么辦？現(xiàn)在我們的前提是先寫redo log，再寫binlog，我們來看看：

• 如果寫redo log失敗了，那我們就認(rèn)為這次事務(wù)有問題，回滾，不再寫binlog。

• 如果寫redo log成功了，寫binlog，寫binlog寫一半了，但失敗了怎么辦？我們還是會(huì)對(duì)這次的事務(wù)回滾，將無效的binlog給刪除（因?yàn)閎inlog會(huì)影響從庫的數(shù)據(jù)，所以需要做刪除操作）

• 如果寫redo log和binlog都成功了，那這次算是事務(wù)才會(huì)真正成功。

簡單來說：MySQL需要保證redo log和binlog的數(shù)據(jù)是一致的，如果不一致，那就亂套了。

• 如果redo log寫失敗了，而binlog寫成功了。那假設(shè)內(nèi)存的數(shù)據(jù)還沒來得及落磁盤，機(jī)器就掛掉了。那主從服務(wù)器的數(shù)據(jù)就不一致了。（從服務(wù)器通過binlog得到最新的數(shù)據(jù)，而主服務(wù)器由于redo log沒有記載，沒法恢復(fù)數(shù)據(jù)）

• 如果redo log寫成功了，而binlog寫失敗了。那從服務(wù)器就拿不到最新的數(shù)據(jù)了。

MySQL通過兩階段提交來保證redo log和binlog的數(shù)據(jù)是一致的。

過程：

• 階段1：InnoDBredo log 寫盤，InnoDB 事務(wù)進(jìn)入 prepare 狀態(tài)

• 階段2：binlog 寫盤，InooDB 事務(wù)進(jìn)入 commit 狀態(tài)

• 每個(gè)事務(wù)binlog的末尾，會(huì)記錄一個(gè) XID event，標(biāo)志著事務(wù)是否提交成功，也就是說，恢復(fù)過程中，binlog 最后一個(gè) XID event 之后的內(nèi)容都應(yīng)該被 purge。

四、什么是undo log

undo log有什么用？

undo log主要有兩個(gè)作用：回滾和多版本控制(MVCC)

在數(shù)據(jù)修改的時(shí)候，不僅記錄了redo log，還記錄undo log，如果因?yàn)槟承┰驅(qū)е率聞?wù)失敗或回滾了，可以用undo log進(jìn)行回滾

undo log主要存儲(chǔ)的也是邏輯日志，比如我們要insert一條數(shù)據(jù)了，那undo log會(huì)記錄的一條對(duì)應(yīng)的delete日志。我們要update一條記錄時(shí)，它會(huì)記錄一條對(duì)應(yīng)相反的update記錄。

這也應(yīng)該容易理解，畢竟回滾嘛，跟需要修改的操作相反就好，這樣就能達(dá)到回滾的目的。因?yàn)橹С只貪L操作，所以我們就能保證：“一個(gè)事務(wù)包含多個(gè)操作，這些操作要么全部執(zhí)行，要么全都不執(zhí)行”。【原子性】

因?yàn)閡ndo log存儲(chǔ)著修改之前的數(shù)據(jù)，相當(dāng)于一個(gè)前版本，MVCC實(shí)現(xiàn)的是讀寫不阻塞，讀的時(shí)候只要返回前一個(gè)版本的數(shù)據(jù)就行了。

最后

這篇文章把binlog /redo log/undo log最核心的知識(shí)給講了，還有一些細(xì)節(jié)性的東西可以自行去補(bǔ)充（比如binlog有幾種的模式，以及文章提到的刷盤策略等等）

如果覺得學(xué)到了，請(qǐng)給我個(gè)贊行不行。

參考資料：

• https://www.jianshu.com/p/4bcfffb27ed5

• https://yq.aliyun.com/articles/617335

• MySQL的ACID原理！

• MySQL 是如何實(shí)現(xiàn) ACID 中的 D 的？

• https://www.cnblogs.com/myseries/p/10728533.html

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

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

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的原来MySQL面试还会问这些...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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