老弟啊！你都工做3年了，連binlog redo log都。。。不該該啊

前段時間，有一個讀者後臺問我：民工哥，我前幾天去面試，就由於我簡歷上寫着精通 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呢？

• 一、redo log的大小是固定的，日誌上的記錄修改落盤後，日誌會被覆蓋掉，沒法用於數據回滾/數據恢復等操做。
• 二、redo log是innodb引擎層實現的，並非全部引擎都有。

基於以上，binlog必不可少

• 一、binlog是server層實現的，意味着全部引擎均可以使用binlog日誌
• 二、binlog經過追加的方式寫入的，可經過配置參數max\_binlog\_size設置每一個binlog文件的大小，當文件大小大於給定值後，日誌會發生滾動，以後的日誌記錄到新的文件上。
• 三、binlog有兩種記錄模式，statement格式的話是記sql語句， row格式會記錄行的內容，記兩條，更新前和更新後都有。

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

如今咱們再來看看整個完整的流程圖

相關參數設置建議

• 一、innodb_flush_log_at_trx_commit：設置爲1，表示每次事務的redolog都直接持久化到磁盤（注意是這裏指的是redolog日誌自己落盤），保證mysql重啓後數據不丟失。
• 二、sync_binlog：設置爲1，表示每次事務的binlog都直接持久化到磁盤（注意是這裏指的是binlog日誌自己落盤），保證mysql重啓後binlog記錄是完整的。

做者：會玩code
連接：https://www.jianshu.com/p/4bc...