前言

MySQL 日志包含了錯誤日志、查詢日志、慢查詢日志、事務日志、二進制日志等，如果存儲引擎使用的是 InnoDB ，二進制日志(binlog)和事務日志(包括redo log和undo log) 是肯定繞不過去的，本篇接下來詳細為大家介紹這三種日志。

redo log

為什么要有 redo log ？

我們都清楚，事務的四大特性其中有一個是持久性，簡單的說就是只要事務提交成功，對數據庫做的修改就會被永久保存下來，不會因為任何原因再回到原來的狀態。

MySQL 是怎么樣保證持久性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數據頁全部刷新回磁盤中，可是這么做存在嚴重的性能問題：

單個事務可能涉及修改多個數據頁，并且數據頁在物理上并不連續，使用隨機IO寫入性能太差。

Innodb是以頁為單位進行磁盤交互的，一個事務有可能只會修改一個數據頁中的幾個字節，如果這時候將完整的數據頁刷回磁盤的話，很浪費資源。

因此 MySQL 設計出了redo log，當一條記錄更新的時候， InnoDB 引擎會先把記錄寫到 redo log 里面去，同時更新內存，這樣就算這條數據更新成功了，完美地解決了性能問題(文件更小并且是順序IO)。

注意此時數據并沒有更新到磁盤上，InnoDB 會在恰當的時候把這條記錄更新到磁盤上去。這種先寫日志然后再將數據刷盤的機制，有個專有名詞——WAL（Write-ahead logging）。

redo log 如何刷到磁盤的呢？

redo log包含兩部分：

內存中的日志緩沖(redo log buffer)

磁盤上的日志文件(redo log file)

每執行一條DML語句，數據庫先將記錄寫入redo log buffer，然后后續某個時間點再一次性將多個操作記錄寫到redo log file。MySQL 一共支持三種寫入redo log file的時機，通過參數innodb_flush_log_at_trx_commit進行配置，如下圖所示：

bin log

bin log 是 MySQL 的邏輯日志，由Server層進行記錄，用于記錄數據庫執行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。無論你使用的是任何的存儲引擎，mysql數據庫都會記錄binlog日志。

與redo log日志一樣，binlog也有自己的刷盤策略，通過sync_binlog參數控制：

0 ：每次提交事務前將binlog寫入os cache，由操作系統控制什么時候刷到磁盤

1 ：采用同步寫磁盤的方式來寫binlog，不使用os cache來寫binlog

N ：當每進行n次事務提交之后，調用一次fsync() os cache中的binlog強制刷到磁盤

bin log 和 redo log 都用于記錄的修改之后的值，那么它們之間究竟有什么區別呢？

redo log 和 binlog 的區別

主要有以下三方面：

binlog 是 MySQL 的 Server 層實現的，所有的引擎都是可以的。redo log是InnoDB的日志。如果不使用InnoDB引擎，是沒有redo log的。

binlog是邏輯日志，記錄的是對哪一個表的哪一行做了什么修改；redo log是物理日志，記錄的是對哪個數據頁中的哪個記錄做了什么修改，可以理解為對磁盤上的哪個數據做了修改。

redo log 是有固定大小的，所以它的空間會用完，如果用完的話，一定要進行一些寫入磁盤的操作才可以繼續; binlog 是可以追加寫入的，也就是 binlog 沒有空間的概念，一直寫就行了

undo log

數據庫事務四大特性中有一個是原子性，原子性指對數據庫的一系列操作，要么全部成功，要么全部失敗，不可能出現部分成功的情況。實際上，原子性底層就是通過undo log實現的。

undo log主要記錄了數據的邏輯變化，比如一條UPDATE語句，對應一條相反UPDATE的undo log，一條INSERT語句，對應一條DELETE的undo log，這樣在發生錯誤時，就能回滾到事務之前的數據狀態。

undo log 同時也是MVCC(多版本并發控制)實現的關鍵。

總結

redo log是InnoDB存儲引擎的一種日志，主要作用是崩潰恢復，刷盤策略參數 innodb_flush_log_at_trx_commit 推薦設置成2。

binlog是MySQL Server層的一種日志，主要作用是歸檔。

undo log是InnoDB存儲引擎的一種日志，主要作用是回滾。

審核編輯：湯梓紅