前言：

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

1.重做日志（redo log）

我們都知道，事務(wù)的四大特性里面有一個(gè)是 持久性 ，具體來(lái)說(shuō)就是只要事務(wù)提交成功，那么對(duì)數(shù)據(jù)庫(kù)做的修改就被永久保存下來(lái)了，不可能因?yàn)槿魏卧蛟倩氐皆瓉?lái)的狀態(tài)。那么 MySQL 是如何保證一致性的呢？最簡(jiǎn)單的做法是在每次事務(wù)提交的時(shí)候，將該事務(wù)涉及修改的數(shù)據(jù)頁(yè)全部刷新到磁盤(pán)中。但是這么做會(huì)有嚴(yán)重的性能問(wèn)題，主要體現(xiàn)在兩個(gè)方面：

因?yàn)?Innodb 是以頁(yè)為單位進(jìn)行磁盤(pán)交互的，而一個(gè)事務(wù)很可能只修改一個(gè)數(shù)據(jù)頁(yè)里面的幾個(gè)字節(jié)，這個(gè)時(shí)候?qū)⑼暾臄?shù)據(jù)頁(yè)刷到磁盤(pán)的話，太浪費(fèi)資源了。 一個(gè)事務(wù)可能涉及修改多個(gè)數(shù)據(jù)頁(yè)，并且這些數(shù)據(jù)頁(yè)在物理上并不連續(xù)，使用隨機(jī) IO 寫(xiě)入性能太差。

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

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

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

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

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

2.回滾日志（undo log）

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

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

innodb_max_undo_log_size：控制最大 undo tablespace 文件的大小，當(dāng)啟動(dòng)了innodb_undo_log_truncate 時(shí)，undo tablespace 超過(guò) innodb_max_undo_log_size 閥值時(shí)才會(huì)去嘗試truncate。該值默認(rèn)大小為1G，truncate后的大小默認(rèn)為10M。 innodb_undo_tablespaces：設(shè)置 undo 獨(dú)立表空間個(gè)數(shù)，范圍為0-128，5.7版本默認(rèn)為0，0表示不開(kāi)啟獨(dú)立undo表空間。該參數(shù)只能在最開(kāi)始初始化 MySQL 實(shí)例的時(shí)候指定。 innodb_undo_directory：設(shè)置 undo 表空間的存放目錄，默認(rèn)數(shù)據(jù)目錄。 innodb_undo_log_truncate：設(shè)置 undo 表空間是否自動(dòng)截?cái)嗷厥铡Ｔ搮?shù)生效的前提是，已設(shè)置獨(dú)立表空間且獨(dú)立表空間個(gè)數(shù)大于等于2個(gè)。

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

總結(jié)：

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