其他：

事务开端之前，将当前是的版本生成undo log，undo 也会产生 redo 来包管undo log的靠得住性

什么时坷矸⑴：

当事务提交之后，undo log并不克不及立马被删除，而是放入待清理的链表，由purge线程断定是否由其他事务在应用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日记空间。

innodb_undo_logs = 128 –回滚段为128KB

对应的物理文件：

MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目次中。

什么时刻产生：

MySQL5.6之后，undo表空间可以设备成自力的文件，然则提前须要在设备文件中设备，完成数据库初始化后生效且弗成改变undo log文件的个数

如不雅初始化数据库之前没有进行相干设备，那么就无法设备成自力的表空间了。

关于MySQL5.7之后的自力undo 表空间设备参数如下：

innodb_undo_directory = /data/undospace/ –undo自力表空间的存放目次

innodb_undo_tablespaces = 4 –指定有4个undo log文件

如不雅undo应用的共享表空间，这个共享表空间中又不仅仅是存储了undo的信息，共享表空间的默认为与MySQL的数据目次下面，其属性由参数innodb_data_file_path设备。

undo是在事务开端之前保存的被修改数据的一个版本，产生undo日记的时刻，同样会伴随类似于保护事务持久化机制的redolog的产生。

默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中产生一些大年夜的事务性操作的时刻，要生成大年夜量的undo信息，全部保存在共享表空间中的。

是以共享表空间可能会变的很大年夜，默认情况下，也就是undo 日记应用共享表空间的时刻，被“撑大年夜”的共享表空间是不会也不克不及主动紧缩的。

是以，mysql5.7之后的“自力undo 表空间”的设备就显得很有须要了。

设备文件的路径为log_bin_basename，binlog日记文件按照指定大年夜小，当日记文件达到指定的最大年夜的大年夜小之后，进行滚动更新，生成新的日记文件。

二进制日记（binlog）：