快，開篇大伙先思考一個問題，mysql 是怎么保證數據不丟失的呢？

其實要保證數據不丟失，說白了要具有下面兩種能力：
（1）能恢復到任何時間點的狀態；
（2）能保證 mysql 在任何時間段突然宕機重啟，已提交的數據不會丟失，未提交完整的數據也會自動回滾；

這不就引出來今天要聊的主題了么，實現第一點需要用 bin log，實現第二點需要用 redo log 和 undo log。

了解三大log之前，我們先看一下mysql數據更新的流程：

上面這張圖包含了 redo log、bin log、undo log 三種日志之間的大致關系，下面進入正題。

一、redo log 重做日志（mysql 存儲引擎 innodb 的事務日志）

我們知道 mysql 數據存在磁盤中，每次讀寫數據需做磁盤 io，并發場景下性能差。為此 mysql 引入緩存 buffer pool 做優化。其包含磁盤中部分數據頁（page）的映射，來緩解數據庫的磁盤壓力。

當從數據庫讀數據時，首先從緩存中讀，緩存中沒有，則從磁盤讀后放入緩存；當向數據庫寫數據時，先向緩存中寫，此時緩存中的數據頁數據會變更，該數據頁叫臟頁，buffer pool 中修改完數據后會按照設定的策略再定期刷到磁盤中去，這個過程叫刷臟頁。

那么問題來了，如果 buffer pool 中修改的數據還沒有及時的刷到磁盤，mysql 宕機重啟，就會導致數據丟失，無法保證事務的持久性，怎么辦？

redo log 解決了這個問題。就是說數據庫在修改數據時，會把更新記錄先寫到 redo log 中，再去修改 buffer pool 中的數據，當提交事務時，調用 fsync 把 redo log 刷入磁盤。至于緩存中更新的數據文件何時刷入磁盤，則由后臺線程異步處理。

注意：此時 redo log 的事務狀態是 prepare，還未真正提交成功，要等 bin log 日志寫入磁盤完成后才會變為 commit，事務才算真正提交成功。

redo log 的寫入方式？

redo log 采用大小固定，循環寫入的方式，當寫滿后，會重新從頭開始循環寫，類似一個環狀。這樣設計原因是 redo log 記錄的是數據頁上的修改，如果 buffer pool 中數據頁已經刷到磁盤，這些記錄就失效了，新日志會將這些失效的記錄覆蓋擦除。

注意：redo log 滿了，在擦除之前，要確保這些要被擦除記錄都已經刷到磁盤中了。在擦除舊記錄釋放新空間期間，不能再接收新的更新請求，此時 mysql 性能會下降。因此高并發情況下，合理調整 redo log 大小很重要。

crash-safe 能力是什么？

innodb 引擎有 crash-safe 能力，即事務提交過程中任何階段，mysql 宕機重啟后都能保證事務的完整性，已提交的數據不會丟失。這種能力是通過redo log保證的，mysql 宕機重啟，系統將自動檢查 redo log，將修改還未寫入磁盤的數據從 redo log 恢復到 mysql 中。

二、undo log 回滾日志（mysql 存儲引擎 innodb 的事務日志）

undo log 記錄的是數據修改之前的狀態，屬于邏輯日志，起到回滾的作用，是保證事務原子性的關鍵。
舉個栗子：假如更新 id=1 記錄的 name 字段，name 原始數據為小王，現改 name 為小張，事務執行 update x set name = 小張 where id =1 語句時，先在 undo log 中記錄一條相反邏輯的 update x set name = 小王 where id =1 記錄，這樣當某些原因導致事務失敗，就可借助 undo log 將數據回滾到事務執行前的狀態。

那么問題來了：同一個事務的一條記錄被多次修改，難道每次都要把數據修改前的狀態寫 undo log 嗎？

不會，因為 undo log 只記錄事務開始前數據的原始版本，當再次對這行數據修改時，產生的修改記錄會寫到 redo log。undo log 負責回滾，redo log負責前滾。

啥是回滾和前滾？

（1）回滾

未提交的事務，即事務未執行 commit。但事務內修改的臟頁中，有一部分已刷盤。此時數據庫宕機重啟，需要回滾來將先前那部分已經刷盤的臟塊從磁盤上撤銷。

（2）前滾

未完全提交的事務，即事務已經執行 commit，但該事務內修改的臟頁中只有一部分數據被刷盤，另一部分還在 buffer pool，此時數據庫宕機重啟，就要用前滾來將未來得及刷盤的數據從 redo log 中恢復出來并刷盤。 

三、bin log 歸檔日志（數據庫 server 層二進制邏輯日志、和什么引擎無關）

bin log 記錄了用戶對數據庫所有 sql 操作（不包含查詢語句，因為這類操作對數據本身沒有修改）。之所以可以稱為歸檔日志，是因為它不會像 redo log 那樣循環擦除之前的記錄，而是會一直記錄日志。一個 bin log 文件默認最大容量1g（可通過 max_binlog_size 參數修改），單個日志超過最大值則會新創建一個文件繼續寫。
注意：日志可能是基于事務來記錄的，而事務不應該跨文件記錄，如果 binlog 日志文件達到了最大值但剛好事務還沒有提交，此時則不會創建新文件記錄，而是繼續增大日志。因此 max_binlog_size 的值和實際的 binlog 文件大小不一定相等。

經過上述介紹，binlog 主要用就是主從同步和數據庫基于時間點的還原。

那么問題來了，可以沒有 binlog 嗎（有了 redo log 為啥還需要 bin log）？

需要分場景來看：

主從模式下，binlog 是必須的，因為從庫的數據同步需要依賴 binlog；

單機模式下，不考慮數據庫基于時間點的還原，binlog 就不是必須的，因為有 redo log 就可以保證 crash-safe 能力了；

redo log 的記錄修改落盤后，日志會被覆蓋掉，無法用于數據恢復等操作，redo log 是 innodb 引擎層實現的，并不是所有引擎都有；

redo log 與 bin log 的區別？

 什么是 redo log 兩階段提交，為什么要這么做？
更新內存后引擎層寫 redo log 將狀態改成 prepare 為提交第一階段，server 層寫 bin log，將狀態改成 commit 為提交第二階段。 兩階段提交目的是確保 binl og 和 redo log 數據一致性。

如果不是兩階段提交可能會出現什么情況？
1）假設先寫 redo log 再寫 bin log，即 redo log 沒有 prepare 階段，寫完直接置為commit，然后再寫 bin log。如果寫完 redo log 后還沒寫完 bin log 數據庫宕機了，重啟后系統自動用 redo log 恢復，此時會造成磁盤上數據頁數據比 bin log 上的記錄數據多，數據不一致。
2）假設先寫 bin log 再寫 redo log，如果寫完 bin log 沒寫完 redo log 數據庫宕機了，那么 bin log 上的記錄就會比磁盤上數據頁的記錄多一些，下次用 bin log 恢復數據，恢復后的數據和原來的數據不一致。

描述一下 redo log 容災恢復過程？
如果 redo log 是完整（commit 狀態）的，直接用 redo log 恢復；
如果 redo log 是預提交 prepare 但不是 commit 狀態，此時要去判斷 binlog 是否完整，如果完整（commit）那就提交 redo log，再用 redo log 恢復，不完整就回滾事務。

 到此這篇關于mysql數據庫面試必備之三大log介紹的文章就介紹到這了,更多相關mysql三大log內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！

原文鏈接：https://blog.csdn.net/Destiny_shine/article/details/121919372