前段時間，有一個讀者后臺問我：民工哥，我前幾天去面試，就因為我簡歷上寫著精通 MySQL，面試官就一個勁的追著我問：什么 binlog，redo log，而且還是怎么細就怎么問，搞我的一臉懵逼。。。

當時，我也看到這話也是一臉懵逼的狀態，只是呵呵一笑，回了他一句：老弟，你都工作 3 年了，連 bin log、redo log 都不知道，不應該啊。。。

所以，今天，民工哥就上次那位讀者遇到的問題，分享一下這方面相關的知識，希望對后面要去面試，或者學習這塊的讀者有一定幫助或參考價值。如果你感覺文章對你有用，請不要吝嗇你的在看與轉發支持，民工哥在這先謝謝大家了。

首先，我們先來看看一次查詢/更新語句流程圖

本文會將重點放在執行器<->存儲引擎之間的交互。

mysql不是每次數據更改都立刻寫到磁盤，而是會先將修改后的結果暫存在內存中,當一段時間后，再一次性將多個修改寫到磁盤上，減少磁盤io成本，同時提高操作速度。

mysql通過WAL(write-ahead logging)技術保證事務

在同一個事務中，每當數據庫進行修改數據操作時，將修改結果更新到內存后，會在redo log添加一行記錄記錄“需要在哪個數據頁上做什么修改”，并將該記錄狀態置為prepare，等到commit提交事務后，會將此次事務中在redo log添加的記錄的狀態都置為commit狀態，之后將修改落盤時，會將redo log中狀態為commit的記錄的修改都寫入磁盤。過程如下圖

redo log記錄方式

redolog 的大小是固定的，在 mysql 中可以通過修改配置參數innodb_log_files_in_group 和 innodb_log_file_size 配置日志文件數量和每個日志文件大小，redolog 采用循環寫的方式記錄，當寫到結尾時，會回到開頭循環寫日志。如下圖

write pos表示日志當前記錄的位置，當ib_logfile_4寫滿后，會從ib_logfile_1從頭開始記錄；check point表示將日志記錄的修改寫進磁盤，完成數據落盤，數據落盤后checkpoint會將日志上的相關記錄擦除掉，即write pos->checkpoint之間的部分是redo log空著的部分，用于記錄新的記錄，checkpoint->write pos之間是redo log待落盤的數據修改記錄。當writepos追上checkpoint時，得先停下記錄，先推動checkpoint向前移動，空出位置記錄新的日志。建議收藏備查！MySQL 常見錯誤代碼說明

有了redo log，當數據庫發生宕機重啟后，可通過redo log將未落盤的數據恢復，即保證已經提交的事務記錄不會丟失。

有了redo log，為啥還需要binlog呢？

•  1、redo log的大小是固定的，日志上的記錄修改落盤后，日志會被覆蓋掉，無法用于數據回滾/數據恢復等操作。
•  2、redo log是innodb引擎層實現的，并不是所有引擎都有。

基于以上，binlog必不可少

•  1、binlog是server層實現的，意味著所有引擎都可以使用binlog日志
•  2、binlog通過追加的方式寫入的，可通過配置參數max_binlog_size設置每個binlog文件的大小，當文件大小大于給定值后，日志會發生滾動，之后的日志記錄到新的文件上。
•  3、binlog有兩種記錄模式，statement格式的話是記sql語句， row格式會記錄行的內容，記兩條，更新前和更新后都有。

binlog和redo log必須保持一致，不允許出現binlog有記錄但redolog沒有的情況，反之亦然。之前說過在一個事務中，redolog有prepare和commit兩種狀態，所以，在redolog狀態為prepare時記錄binlog可保證兩日志的記錄一致，下圖列出各種情況來說明。

現在我們再來看看整個完整的流程圖

相關參數設置建議

•  1、innodb_flush_log_at_trx_commit：設置為1，表示每次事務的redolog都直接持久化到磁盤（注意是這里指的是redolog日志本身落盤），保證mysql重啟后數據不丟失。
•  2、sync_binlog：設置為1，表示每次事務的binlog都直接持久化到磁盤（注意是這里指的是binlog日志本身落盤），保證mysql重啟后binlog記錄是完整的。