本文作者粗略地總結了 MySQL 三種日志的一些特點和作用，以幫助大家理解 MySQL 中的事物以及事物背后的原理。

MySQL中有七種日志文件，分別是：

• 重做日志（redo log）
• 回滾日志（undo log）
• 二進制日志（binlog）
• 錯誤日志（errorlog）
• 慢查詢日志（slow query log）
• 一般查詢日志（general log）
• 中繼日志（relay log）

其中重做日志和回滾日志與事務操作息息相關，二進制日志也與事務操作有一定的關系，這三種日志，對理解 MySQL 中的事務操作有著重要的意義。這里簡單總結一下這三個具有一定相關性的日志。

重做日志（redo log）

作用

重做日志（redo log）的作用是確保事務的持久性，防止在發生故障的時間點，尚有臟頁未寫入磁盤。

在重啟 MySQL 服務的時候，根據 redo log 進行重做，從而達到事務的持久性這一特性。

內容

物理格式的日志，記錄的是物理數據頁面修改的信息，其 redo log 是順序寫入 redo log file 的物理文件中去的。

什么時候產生

事務開始之后就產生 redo log，redo log 的落盤并不是隨著事務的提交才寫入的，而是在事務的執行過程中，便開始寫入 redo log 文件中。

什么時候釋放

當對應事務的臟頁寫入到磁盤之后，redo log 的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。

對應的物理文件

默認情況下，對應的物理文件位于數據庫的 data 目錄下的 ib_logfile1&ib_logfile2。

innodb_log_group_home_dir 指定日志文件組所在的路徑，默認./ ，表示在數據庫的數據目錄下，innodb_log_files_in_group 指定重做日志文件組中文件的數量，默認為 2。

關于文件的大小和數量，由以下兩個參數配置：

• innodb_log_file_size 重做日志文件的大小。
• innodb_mirrored_log_groups 指定了日志鏡像文件組的數量，默認 1。

其他

很重要一點，redo log 是什么時候寫盤的？前面說了是在事物開始之后逐步寫盤的。

之所以說重做日志是在事務開始之后逐步寫入重做日志文件，而不一定是事務提交才寫入重做日志緩存。

原因就是，重做日志有一個緩存區 Innodb_log_buffer，Innodb_log_buffer 的默認大小為 8M(這里設置的 16M)，Innodb 存儲引擎先將重做日志寫入 innodb_log_buffer 中。

然后會通過以下三種方式將 Innodb 日志緩沖區的日志刷新到磁盤：

• Master Thread 每秒一次執行刷新 Innodb_log_buffer 到重做日志文件。
• 每個事務提交時會將重做日志刷新到重做日志文件。
• 當重做日志緩存可用空間少于一半時，重做日志緩存被刷新到重做日志文件。

由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對于***種方式，Innodb_log_buffer 到重做日志文件是 Master Thread 線程的定時任務。

因此重做日志的寫盤，并不一定是隨著事務的提交才寫入重做日志文件的，而是隨著事務的開始，逐步開始的。

另外引用《MySQL技術內幕 Innodb 存儲引擎》（page37）上的原話：

即使某個事務還沒有提交，Innodb 存儲引擎仍然每秒會將重做日志緩存刷新到重做日志文件。

這一點是必須要知道的，因為這可以很好地解釋再大的事務提交（commit）的時間也是很短暫的。

回滾日志（undo log）

作用

保存了事務發生之前的數據的一個版本，可以用于回滾，同時可以提供多版本并發控制下的讀（MVCC），也即非鎖定讀。

內容

邏輯格式的日志，在執行 undo 的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，而不是從物理頁面上操作實現的，這一點是不同于 redo log 的。

什么時候產生

事務開始之前，將當前時的版本生成 undo log，undo 也會產生 redo 來保證 undo log 的可靠性。

什么時候釋放

當事務提交之后，undo log 并不能立馬被刪除，而是放入待清理的鏈表，由 purge 線程判斷是否由其他事務在使用 undo 段中表的上一個事務之前的版本信息，決定是否可以清理 undo log 的日志空間。

對應的物理文件

MySQL 5.6 之前，undo 表空間位于共享表空間的回滾段中，共享表空間的默認名稱是 ibdata，位于數據文件目錄中。

MySQL 5.6 之后，undo 表空間可以配置成獨立的文件，但是提前需要在配置文件中配置，完成數據庫初始化后生效且不可改變 undo log 文件的個數。

如果初始化數據庫之前沒有進行相關配置，那么就無法配置成獨立的表空間了。

關于 MySQL 5.7 之后的獨立 undo 表空間配置參數如下：

• innodb_undo_directory = /data/undospace/ –undo 獨立表空間的存放目錄
• innodb_undo_logs = 128 –回滾段為 128KB
• innodb_undo_tablespaces = 4 –指定有 4 個 undo log 文件

如果 undo 使用的共享表空間，這個共享表空間中又不僅僅是存儲了 undo 的信息，共享表空間將默認位于 MySQL 的數據目錄下面，其屬性由參數 innodb_data_file_path 配置。

其他

undo 是在事務開始之前保存的被修改數據的一個版本，產生 undo 日志的時候，同樣會伴隨類似于保護事務持久化機制的 redolog 的產生。

默認情況下 undo 文件是保持在共享表空間的，也即 ibdatafile 文件中，當數據庫中發生一些大的事務性操作的時候，要生成大量的 undo 信息，全部保存在共享表空間中的。

因此共享表空間可能會變的很大，默認情況下，也就是 undo 日志使用共享表空間的時候，被“撐大”的共享表空間是不會也不能自動收縮的。

因此，MySQL 5.7 之后的“獨立 undo 表空間”的配置就顯得很有必要了。

二進制日志（binlog）

作用

用于復制，在主從復制中，從庫利用主庫上的 binlog 進行重播，實現主從同步；用于數據庫基于時間點的還原。

內容

邏輯格式的日志，可以簡單認為就是執行過的事務中的 SQL 語句，但又不完全是 SQL 語句這么簡單。

它包括了執行的 SQL 語句（增刪改）反向的信息，也就意味著 delete 對應著 delete 本身和其反向的 insert；update 對應著 update 執行前后的版本的信息；insert 對應著 delete 和 insert 本身的信息。

在使用 MySQLbinlog 解析 binlog 之后一些都會真相大白。因此可以基于 binlog 做到類似于 Oracle 的閃回功能，其實都是依賴于 binlog 中的日志記錄。

什么時候產生

事務提交的時候，一次性將事務中的 SQL 語句（一個事物可能對應多個 SQL 語句）按照一定的格式記錄到 binlog 中。

這里與 redo log 很明顯的差異就是 redo log 并不一定是在事務提交的時候刷新到磁盤，redo log 是在事務開始之后就開始逐步寫入磁盤。

因此對于事務的提交，即便是較大的事務，提交（commit）都是很快的，但是在開啟了 bin_log 的情況下，對于較大事務的提交，可能會變得比較慢一些。

這是因為 binlog 是在事務提交的時候一次性寫入造成的，這些可以通過測試驗證。

什么時候釋放

binlog 默認是保持時間由參數 expire_logs_days 配置，也就是說對于非活動的日志文件，在生成時間超過 expire_logs_days 配置的天數之后，會被自動刪除。

對應的物理文件

配置文件的路徑為 log_bin_basename，binlog 日志文件按照指定大小，當日志文件達到指定的***的大小之后，進行滾動更新，生成新的日志文件。

對于每個 binlog 日志文件，通過一個統一的 index 文件來組織。

其他

二進制日志的作用之一是還原數據庫，這與 redo log 很類似，很多人混淆過，但是兩者有本質的不同：

• 作用不同：redo log 是保證事務的持久性的，是事務層面的；binlog 作為還原的功能，是數據庫層面的（當然也可以精確到事務層面的）。雖然都有還原的意思，但是其保護數據的層次是不一樣的。
• 內容不同：redo log 是物理日志，是數據頁面修改之后的物理記錄，binlog 是邏輯日志，可以簡單認為記錄的就是 SQL 語句。
• 另外，兩者日志產生的時間、可以釋放的時間，在可釋放的情況下清理機制，都是完全不同的。
• 恢復數據時候的效率，基于物理日志的 redo log 恢復數據的效率要高于語句邏輯日志的 binlog。

關于事務提交時，redo log 和 binlog 的寫入順序，為了保證主從復制時候的主從一致（當然也包括使用 binlog 進行基于時間點還原的情況），是要嚴格一致的。

MySQL 通過兩階段提交過程來完成事務的一致性的，也即 redo log 和 binlog 的一致性，理論上是先寫 redo log，再寫 binlog，兩個日志都提交成功（刷入磁盤），事務才算真正的完成。

總結

MySQL 中，對于以上三種日志，每一種細化起來都可以夠寫一個章節的，這里粗略地總結了一下三種日志的一些特點和作用，以幫助理解 MySQL 中的事物以及事物背后的原理。