前言：

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

1.重做日志（redo log）

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

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

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

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

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

• innodb_log_files_in_group：redo log 文件的個數(shù)，命名方式如：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 文件組所在的路徑，默認./ ，表示在數(shù)據(jù)庫的數(shù)據(jù)目錄下。
• innodb_log_buffer_size：redo log buffer 大小，默認16M。延遲事務日志寫入磁盤，把 redo log 放到該緩沖區(qū)，然后根據(jù) innodb_flush_log_at_trx_commit 參數(shù)的設置，再把日志從 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，由系統(tǒng)內部來 fsync 到磁盤文件。如果數(shù)據(jù)庫實例 crash ，不會丟失 redo log，但是如果服務器 crash，由于 file system buffer 還來不及 fsync 到磁盤文件，所以會丟失這一部分的數(shù)據(jù)。值為0，表示事務提交時不進行寫入 redo log 操作，這個操作僅在 master thread 中完成，而在 master thread 中每1秒進行一次重做日志的 fsync 操作，因此實例 crash 最多丟失1秒鐘內的事務。
  

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

2.回滾日志（undo log）

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

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

• 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 獨立表空間個數(shù)，范圍為0-128，5.7版本默認為0，0表示不開啟獨立undo表空間。該參數(shù)只能在最開始初始化 MySQL 實例的時候指定。
• innodb_undo_directory：設置 undo 表空間的存放目錄，默認數(shù)據(jù)目錄。
• innodb_undo_log_truncate：設置 undo 表空間是否自動截斷回收。該參數(shù)生效的前提是，已設置獨立表空間且獨立表空間個數(shù)大于等于2個。
  

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

總結：

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