在MySQL5.7以前，ibdata1文件会逐渐增大(ibdata1文件包含哪些信息?)，非常占用系统空间，特别是一些云数据来说，磁盘非常的贵，想要回收空间，只能进行一次导出和导入操作，来重新生成undo 表空间，从MySQL5.7开始，有了在线回收undo表空间的功能，主要由以下几个参数设置。

innodb_undo_directory = .

为undo文件存储路径。如果没有指定默认值(NULL)，则undo表空间则存放到mysql的data目录里(datadir选项)。配置此项可以用undo从ibdata文件里分离出来。单独存储。

innodb_undo_logs = 128

(默认值 128)undo rollback segment 回滚段个数，为 innodb_rollback_segments 参数选项的别名，最大值为128，其中32个为使用临时表空间 ibtmp1 保留，1个为系统表空间使用，剩余的95个为 undo tablespaces 使用。

当 innodb_rollback_segments<=32的时候，系统将自动分配1个rollback segment给系统表空间，32个分给临时表空间。

此选项以后版本将移除！

innodb_undo_tablespaces = 0

(MySQL5.7默认值为0，MySQL8默认值为2)undo文件个数，此值需要在MySQL Server 初始化的时候指定，一经设定，以后将无法修改，否则重启后会提示部分Undo 文件找不到。默认值为0, 此时无法进行Undo回收操作，回收undo表空间至少需要为2个才可以， 需保证其中一个进行回收收缩时，另一个为可用状态。保存路径为 innodb_undo_directory选项设置，undo文件名规则为 undoN。文件大小受innodb_page_size选项影响。

此选项以后版本将移除！

innodb_undo_log_truncate = OFF

(默认值NO)参数设置为ON，即开启在线回收undo日志文件，支持动态设置，当超过 innodb_max_undo_log_size 时被进行收缩，至少需要两个undo文件，即innodb_undo_tablespace>=2

innodb_max_undo_log_size = 1073741824

(默认1GB)当超过阈值时，会触发truncate回收动作，truncate后空间缩小到10MB

innodb_purge_rseg_truncate_frequency = 128

(默认值128), 控制回收undo log的频率。 指定purge操作被唤起多少次之后才释放rollback segments。当undo表空间里面的rollback segments被释放时，undo表空间才会被truncate。由此可见，该参数越小，undo表空间被尝试truncate的频率越高。 。

联想思考：

ibdata文件包含哪些信息?

undo logs、change buffer、doublewrite buffer、表数据、索引数据，如果启用了 innodb_file_per_table 选项的话，则表数据和索引数据则存储到相应表的.ibd 文件里)，参考：

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibdata_file

ibdata文件爆增原因有哪些?

事务未提交、大事务、启用了共享表空间、磁盘io过慢导致check point远远落后。等等

如何避免ibdata文件一直爆增的问题?

尽量短事务、增加 purge 线程、加速purge频率(innodb_purge_truncate_frequency)、监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill