在查找到很多資料中，以下文章是 對于參數 innodb_undo_log_truncate 說明最為簡明的一篇文章了，這里做一轉載。
（原文： https://www.linuxidc.com/Linux/2017-05/143400.htm）

MySQL 5.5時代的undo log
在MySQL5.5以及之前，大家會發現隨著數據庫上線時間越來越長，ibdata1文件（即InnoDB的共享表空間，或者系統表空間）會越來越大，這會造成2個比較明顯的問題：
（1）磁盤剩余空間越來越小，到后期往往要加磁盤；
（2）物理備份時間越來越長，備份文件也越來越大。

這是怎么回事呢？
原因除了數據量自然增長之外，在MySQL5.5以及之前，InnoDB的undo log也是存放在ibdata1里面的。一旦出現大事務，這個大事務所使用的undo log占用的空間就會一直在ibdata1里面存在，即使這個事務已經關閉。

那么問題來了，有辦法把上面說的空閑的undo log占用的空間從ibdata1里面清理掉嗎？答案是沒有直接的辦法，只能全庫導出sql文件，然后重新初始化mysql實例，再全庫導入。

MySQL 5.6時代的undo log

MySQL 5.6增加了參數innodb_undo_directory、innodb_undo_logs和innodb_undo_tablespaces這3個參數，可以把undo log從ibdata1移出來單獨存放。

下面對這3個參數做一下解釋：

（1）innodb_undo_directory，指定單獨存放undo表空間的目錄，默認為.（即datadir），可以設置相對路徑或者絕對路徑。該參數實例初始化之后雖然不可直接改動，但是可以通過先停庫，修改配置文件，然后移動undo表空間文件的方式去修改該參數；

（2）innodb_undo_tablespaces，指定單獨存放的undo表空間個數，例如如果設置為3，則undo表空間為undo001、undo002、undo003，每個文件初始大小默認為10M。該參數我們推薦設置為大于等于3，原因下文將解釋。該參數實例初始化之后不可改動；

（3）innodb_undo_logs，指定回滾段的個數（早期版本該參數名字是innodb_rollback_segments），默認128個。每個回滾段可同時支持1024個在線事務。這些回滾段會平均分布到各個undo表空間中。該變量可以動態調整，但是物理上的回滾段不會減少，只是會控制用到的回滾段的個數。

實際使用方面，在初始化實例之前，我們只需要設置innodb_undo_tablespaces參數（建議大于等于3）即可將undo log設置到單獨的undo表空間中。如果需要將undo log放到更快的設備上時，可以設置innodb_undo_directory參數，但是一般我們不這么做，因為現在SSD非常普及。innodb_undo_logs可以默認為128不變。

MySQL 5.7時代的undo log

那么問題又來了，undo log單獨拆出來后就能縮小了嗎？MySQL 5.7引入了新的參數，innodb_undo_log_truncate，開啟后可在線收縮拆分出來的undo表空間。在滿足以下2個條件下，undo表空間文件可在線收縮：

（1）innodb_undo_tablespaces>=2。因為truncate undo表空間時，該文件處于inactive狀態，如果只有1個undo表空間，那么整個系統在此過程中將處于不可用狀態。為了盡可能降低truncate對系統的影響，建議將該參數最少設置為3；

（2）innodb_undo_logs>=35（默認128）。因為在MySQL 5.7中，第一個undo log永遠在系統表空間中，另外32個undo log分配給了臨時表空間，即ibtmp1，至少還有2個undo log才能保證2個undo表空間中每個里面至少有1個undo log；

滿足以上2個條件后，把innodb_undo_log_truncate設置為ON即可開啟undo表空間的自動truncate，這還跟如下2個參數有關：

（1）innodb_max_undo_log_size，undo表空間文件超過此值即標記為可收縮，默認1G，可在線修改；

（2）innodb_purge_rseg_truncate_frequency,指定purge操作被喚起多少次之后才釋放rollback segments。當undo表空間里面的rollback segments被釋放時，undo表空間才會被truncate。由此可見，該參數越小，undo表空間被嘗試truncate的頻率越高。

MySQL 5.7的undo表空間的truncate示例

（1） 首先確保如下參數被正確設置：

為了實驗方便，我們減小該值

innodb_max_undo_log_size = 100M
innodb_undo_log_truncate = ON
innodb_undo_logs = 128
innodb_undo_tablespaces = 3

為了實驗方便，我們減小該值

innodb_purge_rseg_truncate_frequency = 10

（2） 創建表：
mysql> create table t1( id int primary key auto_increment, name varchar(200));
Query OK, 0 rows affected (0.13 sec)

（3）插入測試數據
mysql> insert into t1(name) values(repeat(‘a’,200));
mysql> insert into t1(name) select name from t1;
mysql> insert into t1(name) select name from t1;
mysql> insert into t1(name) select name from t1;
mysql> insert into t1(name) select name from t1;

這時undo表空間文件大小如下，可以看到有一個undo文件已經超過了100M：

-rw-r----- 1 mysql mysql 13M Feb 17 17:59 undo001
-rw-r----- 1 mysql mysql 128M Feb 17 17:59 undo002
-rw-r----- 1 mysql mysql 64M Feb 17 17:59 undo003
此時，為了，讓purge線程運行，可以運行幾個delete語句：

mysql> delete from t1 limit 1;
mysql> delete from t1 limit 1;
mysql> delete from t1 limit 1;
mysql> delete from t1 limit 1;

再查看undo文件大小：

-rw-r----- 1 mysql mysql 13M Feb 17 18:05 undo001
-rw-r----- 1 mysql mysql 10M Feb 17 18:05 undo002
-rw-r----- 1 mysql mysql 64M Feb 17 18:05 undo003
可以看到，超過100M的undo文件已經收縮到10M了。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的MySQL5.7新特性——在线收缩undo表空间 （转载）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。