共計 2124 個字符，預計需要花費 6 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章主要介紹了 MySQL 日志之 redo log 和 binlog 的區別是什么，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。

redo log 和 binlog 的區別

redo log

在 MySQL 中，如果你要更新一條語句，需要帶更新條件，比如 update T set name =‘god-jiang’where id=6，一般都是先查詢到 id= 6 的語句，然后再進行更新操作。

如果更新的數量是 100 條，1000 條甚至 10000 條的時候，每一次更新都需要寫到磁盤上。然后磁盤也要找到對應的記錄，然后再更新，整個過程 IO 成本、查找成本太大，為了解決這個問題，MySQL 的設計者采用了 WAL 技術來解決。WAL 全稱是 Write Ahead Logging，意思就是先寫日志，再寫磁盤。

具體操作：當有一條記錄需要更新的時候，InnoDB 引擎會先把記錄寫到 redo log 中，并更新內存，這個時候更新就算完成了。同時，InnoDB 引擎會在適當的時候（系統空閑時），將這個操作記錄更新到磁盤中，這個更新往往是在系統比較空閑的時候。

但是 redo log 的大小是固定的，不可能一直無限寫，讓我們看下 MySQL 怎么做到的吧。

write pos 是當前記錄的位置，一邊寫一邊往后移動。check point 是當前要擦除的位置，也是往后移動并且循環的，擦除記錄之前要把記錄更新到數據文件中。

write pos 與 check point 之間綠色的部分表示可以記錄新的操作。如果 write pos 追上了 check point，表示 redo log 滿了，這個時候就不能繼續執行新的操作，需要停下擦除一些記錄，并且把 check point 往后推進。

有了 redo log，InnoDB 可以保證即使數據庫發現異常重啟了，也不會丟失之前提交的事務，這個能力也被稱為 crash-safe。

以上就是 redo log 的介紹，看完了之后，你可以試著去問一下你公司的 DBA 同事，MySQL 是否可以恢復到半個月內任意一秒的狀態，得到的答案肯定是可以的，這都要歸功于 redo log 的功勞。

binlog

從 MySQL 整體來看，其實分為兩層，一層是 Server 層，一層是存儲引擎層。上面聊到的 redo log 就是屬于 InnoDB 引擎特有的日志，而 binlog 是屬于 Server 層的日志，也稱為歸檔日志。

redo log 和 binlog 的區別

redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用

redo log 是物理日志，記錄的是“在 XXX 數據頁上做了 XXX 修改”；binlog 是邏輯日志，記錄的是原始邏輯，其記錄是對應的 SQL 語句

redo log 是循環寫的，空間一定會用完，需要 write pos 和 check point 搭配；binlog 是追加寫，寫到一定大小會切換到下一個，并不會覆蓋以前的日志

通過簡單的更新語句演示執行器和 InnoDB 引擎的內部流程

update T set name =  god-jiang  where id = 6

通過執行器從 InnoDB 引擎取出 id= 6 的記錄，然后加載到內存中

執行器拿到引擎返回的結果，把 name 修改為’god-jiang’，再重新調用存儲引擎的接口寫入新數據

引擎將新數據更新到內存中，同時將這個更新操作寫到 redo log 中，此時 redo log 處于 prepare 狀態

執行器生成這個操作的 binlog，并把 binlog 寫到磁盤中

執行器調用引擎提交事務的接口，并且把剛剛寫入的 redo log 改為 commit 狀態，更新完成

對應的流程圖

最后為什么寫入 redo log 會處于 prepare 狀態，然后寫入 binlog 還要變成 commit 狀態？其實這個過程就叫做“兩階段提交”。

兩階段提交

其實 redo log 和 binlog 都可以用于表示事務的提交的狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。

舉例子：update T set name =‘god-jiang’where id = 6 沒有兩階段提交會發生什么？

先寫 redo log 后寫 binlog。假設寫完了 redo log，binlog 還沒有寫完，這個時候 MySQL 異常重啟。因為 redo log 寫完了，恢復系統的時候 name=‘god-jiang’。但是 binlog 沒有寫完，所以 binlog 沒有記錄這條語句，這個時候用 binlog 恢復數據的時候，恢復出來的 name 就是原來值，與 redo log 不同。

同理可得，先寫 binlog 后寫 redo log 也會發現兩個日志恢復的數據不同。這個不一致會導致線上出現主從不一致的情況。

總結

redo log 可以保存 crash-safe 能力，可以保證 MySQL 異常重啟數據不丟失

binlog 可以記錄對應的 SQL 語句，也可以保證 MySQL 異常重啟數據不丟失

提交事務的兩階段提交，可以維持數據邏輯一致性

感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“MySQL 日志之 redo log 和 binlog 的區別是什么”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!