前言
Undo log是InnoDB MVCC事务特性的重要组成部分，对记录做了变更操作时会产生undo记录，默认存储到系统表空间中，但是从5.6开始，可以使用独立的undo表空间。
Undo记录存储的是老版本数据，当一个旧事务需要读取数据时，为了能读取到老版本数据，需要顺着undo连找到满足其可见性的记录。当版本链很长时，可以认为这是要一个比较耗时的操作。
大多数对记录的变更insert、update、delete。Insert操作在事务提交前只对当前事务可见，因此产生的undo日志可以在事务提交后直接删除（没有对刚插入的数据有可见性需求），而对于update、delete则需要维护多版本信息。
Undo tablespace
MySQL5.6可以使用独立undo表空间。innodb_undo_tablespaces：0-126，在系统初始化后该文件大小默认是10M。虽然可以将其从系统表空间提出了，使系统表空间不再因为大事务而迅速不断增大，但是独立出来的undo表空间仍然比较鸡肋，不能truncate。而且也没有相关undo表空间文件大小的阈值。
MySQL5.7.5之后undo表空间可以truncate了。需要配置至少2个undo表空间innodb_undo_spaces=2，undo表空间被删除时临时设置为offline状态，至少有另外一个undo表空间服务才可以让server工作。如果配置成1个undo表空间的话，即使开启truncate也没用，本undo表空间文件会一直增大，甚至撑爆磁盘。
Mysql5.7.5之后版本，set global innodb_undo_log_truncate=on开启truncate功能，innodb_max_undo_log_size为undo表空间文件的阈值，默认1G，超过改值，会自动进行truncate。如果不开启truncate则导致undo表空间文件不断增大。
被选中删除的undo文件，对应的回滚段标记为inactive，purge回收不再使用的回滚段，完成后进行truncate，恢复到10M大小，回滚段再次标记为active。
innodb_undo_logs定义了InnoDB使用的回滚段个数，必须设置35个以上；第一个常驻系统表空间，若使用独立undo表空间，则第一个置为inactive。回滚段2-33在共享临时表空间ibtmp1。34th 35th分别是独立表空间的第一个和第二个。
undo tablesapce和回滚段之间什么关系
可以看到在系统启动的时候创建好undo表空间。默认undo表空间放到系统表空间里面。当将undo表空间独立出来时，undo表空间轮流分给各个回滚段。
可以看到当undo表空间提出了的时候，回滚段是轮询分配给每个事务的，并且不使用系统表空间，保证所有的undo log都存储到undo 独立表空间中。
