前言：

前面文章講述了 MySQL 系統中常見的幾種日志，其實還有事務相關日志 redo log 和 undo log 沒有介紹。相對于其他幾種日志而言， redo log 和 undo log 是更加神秘，難以觀測的。本篇文章將主要介紹這兩類事務日志的作用及運維方法。

1.重做日志（redo log）

我們都知道，事務的四大特性里面有一個是 持久性 ，具體來說就是只要事務提交成功，那么對數據庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態。那么 MySQL 是如何保證一致性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數據頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現在兩個方面：

• 因為 Innodb 是以頁為單位進行磁盤交互的，而一個事務很可能只修改一個數據頁里面的幾個字節，這個時候將完整的數據頁刷到磁盤的話，太浪費資源了。
• 一個事務可能涉及修改多個數據頁，并且這些數據頁在物理上并不連續，使用隨機 IO 寫入性能太差。
  

因此 MySQL 設計了 redo log ，具體來說就是只記錄事務對數據頁做了哪些修改，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)。

redo log 包括兩部分：一個是內存中的日志緩沖（redo log buffer），另一個是磁盤上的日志文件（redo log file）。MySQL 每執行一條 DML 語句，先將記錄寫入 redo log buffer ，后續某個時間點再一次性將多個操作記錄寫到 redo log file 。

默認情況下，redo log 在磁盤上由名為 ib_logfile0 和 ib_logfile1 的兩個物理文件展示。redo log 相關參數簡單介紹如下：

• innodb_log_files_in_group：redo log 文件的個數，命名方式如：ib_logfile0，iblogfile1... iblogfilen。默認2個，最大100個。
• innodb_log_file_size：單個 redo log 文件設置大小，默認值為 48M，最大值為512G，注意最大值指的是整個 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。
• innodb_log_group_home_dir：指定 redo log 文件組所在的路徑，默認./ ，表示在數據庫的數據目錄下。
• innodb_log_buffer_size：redo log buffer 大小，默認16M。延遲事務日志寫入磁盤，把 redo log 放到該緩沖區，然后根據 innodb_flush_log_at_trx_commit 參數的設置，再把日志從 buffer 中 flush 到磁盤中。
• innodb_flush_log_at_trx_commit：控制 redo log 刷新到磁盤的策略，默認為1。值為1，每次 commit 都會把 redo log 從 redo log buffer 寫入到 system ，并 fsync 刷新到磁盤文件中。值為2，每次事務提交時 MySQL 會把日志從 redo log buffer 寫入到 system ，但只寫入到 file system buffer，由系統內部來 fsync 到磁盤文件。如果數據庫實例 crash ，不會丟失 redo log，但是如果服務器 crash，由于 file system buffer 還來不及 fsync 到磁盤文件，所以會丟失這一部分的數據。值為0，表示事務提交時不進行寫入 redo log 操作，這個操作僅在 master thread 中完成，而在 master thread 中每1秒進行一次重做日志的 fsync 操作，因此實例 crash 最多丟失1秒鐘內的事務。
  

更改 redo log 及其 buffer 大小是需要重啟數據庫實例的，建議初始化時做好評估。可以適當加大 redo log 組數和大小，特別是你的數據庫實例更新比較頻繁的情況下。但也不推薦 redo log 設置過大。

2.回滾日志（undo log）

undo log 主要用于保證數據的原子性，保存了事務發生之前的數據的一個版本，可以用于回滾。比如一條 INSERT 語句，對應一條 DELETE 的 undo log ，對于每個 UPDATE 語句，對應一條相反的 UPDATE 的 undo log ，這樣在發生錯誤時，就能回滾到事務之前的數據狀態。同時，undo log 也是 MVCC (多版本并發控制) 實現的關鍵。

MySQL 5.7 版本中，undo log 默認存放在共享表空間 ibdata 中。也可以在初始化時通過配置參數改成獨立的文件，簡單介紹幾個 undo log 相關參數：

• innodb_max_undo_log_size：控制最大 undo tablespace 文件的大小，當啟動了innodb_undo_log_truncate 時，undo tablespace 超過 innodb_max_undo_log_size 閥值時才會去嘗試truncate。該值默認大小為1G，truncate后的大小默認為10M。
• innodb_undo_tablespaces：設置 undo 獨立表空間個數，范圍為0-128，5.7版本默認為0，0表示不開啟獨立undo表空間。該參數只能在最開始初始化 MySQL 實例的時候指定。
• innodb_undo_directory：設置 undo 表空間的存放目錄，默認數據目錄。
• innodb_undo_log_truncate：設置 undo 表空間是否自動截斷回收。該參數生效的前提是，已設置獨立表空間且獨立表空間個數大于等于2個。
  

undo log 相關參數一般很少改動。MySQL 8.0 默認啟用了獨立表空間，可能 undo log 表空間的大小設置更靈活些。

總結：

本篇文章主要介紹了 redo log 及 undo log 的作用和相關參數設置，文章寫的比較匆忙，如有錯誤，可以留言指出。關于這兩類日志更深層次的內容，可能筆者功力還不到，未能寫到更加透徹。好了，MySQL 相關日志的兩篇文章已經寫完了，希望各位能學到一點知識。