背景

Innodb使用undo log来实现MVCC，这意味着如果一个很老的事务长时间不提交，那么新产生的undo log都无法被及时清理掉。在MySQL 5.5及之前版本中，undo log是存储在ibdata中。从5.6开始可以使用独立的undo log表空间来存储undo。但是直到5.6，一旦undo log膨胀，依然没有任何办法为其 “减肥”。因此我们经常看到ibdata被膨胀到几十上百G。

改进

在MySQL5.7.5版本中终于增加了这个众望所归的功能，实现了在线truncate undo log的功能。对应的changeling entry如下：

InnoDB: You can now truncate undo logs that reside in undo tablespaces. This feature is enabled using the innodb_undo_log_truncate configuration option. For more information, see Truncating Undo Logs That Reside in Undo Tablespaces.

在能够使用该特性之前，需要先打开独立undo表空间，注意现在只能在install db的时候才能开启，因为在初始化阶段是写死占用了最小的几个space id的。这种实现方式。。。只能无限吐槽了。

有几个参数控制undo tablespace：

innodb_undo_directory：undo文件的存储目录。

innodb_undo_tablespaces：undo tablespace的个数，实现在线truncate undo，需要大于等于2，因为在truncate一个undo log文件时，要保证另外一个是可用的，这样就无需停止业务了。

innodb_undo_logs：undo回滚段的数量需要大于34。原因是1~32个回滚段会被临时表占用（5.7针对临时表做了大量优化），第33、34分配给undospace1 和undospace2。

这里有个比较有意思的问题，由于undo 回滚段总是从第一个undospace分配，如果每次从1开始，每次重启递增innodb_undo_logs，所有的回滚段都会被分配到第一个undo space，在truncate第一个undo space时，将无可用的undo回滚分配给正常的用户事务。

innodb_purge_rseg_truncate_frequency：用于控制purge回滚段的频度。 Innodb Purge操作的协调线程每隔这么多次purge事务分发后，就会触发一次History purge，并检查当前的undo log 表空间状态是否会触发truncate。

innodb_max_undo_log_size：控制最大undo tablespace文件的大小，超过这个阀值时才会去尝试truncate。truncate后的大小默认为10M。

innodb_undo_log_truncate：用于打开/关闭undo log 在线truncate特性，可动态调整。

undo log 的truncate操作由purge 协调线程发起，在truncate 某个undo log 表空间的过程中，保证有一个可用的undo log tablespace能提供给用户使用，从而实现所谓的在线truncate。

当选定一个需要truncate的undo log space时，需要检查其是否是可释放的，也就是说是否还有活跃的事务可能访问其中的回滚段。如果没有，就将该tablespace中的回滚段设置为不可分配，然后对undo log space文件进行truncate，并重新初始化到10M，初始化文件头等一系列操作。

这里引入了比较有意思的方法来保证truncate的原子性，即在开始truncate时，创建一个独立的文件，命名为undo_<space_id>_trunc.log，在做完truncate操作后，删除文件。如果在中间发生crash，崩溃恢复时发现该文件，会继续完成truncate操作。

更具体的参考WL#6965 及对应补丁Rev:8615