在MySQL5.6中开始支持把undo log分离到独立的表空间，并放到单独的文件目录下；这给咱们部署不一样IO类型的文件位置带来便利，对于并发写入型负载，咱们能够把undo文件部署到单独的高速存储设备上.html
1.使用
有几个参数来控制该行为
用于设定建立的undo表空间的个数，在Install db时初始化后，就不再能被改动了；
默认值为0，表示不独立设置undo的tablespace，默认记录到ibdata中；不然，则在undo目录下建立这么多个undo文件，例如假定设置该值为16，那么就会建立命名为undo001~undo016的undo tablespace文件，每一个文件的默认大小为10M
修改该值可能会致使Innodb没法完成初始化；
用于表示回滚段的个数（早期版本的命名为
innodb_rollback_segments ），该变量能够动态调整，可是物理上的回滚段不会减小，只是会控制用到的回滚段的个数;
默认为128个回滚段
当开启独立undo表空间时，指定undo文件存放的目录
若是咱们想转移undo文件的位置，只须要修改下该配置，并将undo文件拷贝过去就能够了。
2.相关代码
#在innodb启动时(innobase_start_or_create_for_mysql)，会进行undo表空间初始化，细节见函数srv_undo_tablespaces_init
–>若是是新建实例，会去建立undo log文件，undo表空间的space id从1开始；默认初始化大小为10M，由宏SRV_UNDO_TABLESPACE_SIZE_IN_PAGES控制;
–>读取当前实例的全部undo表空间的space id （trx_rseg_get_n_undo_tablespaces）
首先从ibdata中读取到事务系统的文件头，而后再从其中记录的回滚段信息，找到回滚段对应的space id和page no（trx_sysf_rseg_get_space，trx_sysf_rseg_get_page_no），并按照space id排序后返回；
–>根据上一步读到的space id依次打开undo文件(srv_undo_tablespace_open)，若是不存在，就标识启动失败
因此undo文件也是相似ibdata的重要文件，目前是不能够删除的。。。因此不要试图删除undo文件来释放空间- -!
能够容忍定义的table space个数比已有的undo文件个数要少(但全部的undo文件依然会打开)，反之则报错初始化失败
#undo回滚段初始化 （trx_sys_create_rsegs）
若是是正常shutdown重启，而且设置的回滚段个数大于目前已经使用的回滚段个数(trx_sysf_rseg_find_free)，就会去新建回滚段(trx_rseg_create)
这里老是从第一个undolog tablespace开始初始化回滚段，看起来彷佛有些问题，极端状况下，若是我每次重启递增innodb_undo_logs，是否是意味着全部的undo回滚段都会写入到第一个undo tablespace中?
完成初始化后，将当前可用的undo 回滚段的个数复制给srv_available_undo_logs，能够经过show status查看：
root@performance_schema 12:16:18>show status like ‘Innodb_available_undo_logs';
+—————————-+——-+
| Variable_name | Value |
+—————————-+——-+
| Innodb_available_undo_logs | 128 |
+—————————-+——-+
1 row in set (0.00 sec)
启动后，innodb_undo_logs是能够动态调整的，但最大不能够超过Innodb_available_undo_logs
#在一个非只读的事务开启时，会为其分配回滚段(trx_assign_rseg_low)，动态的调整innodb_undo_logs能够限定分配的回滚段范围；
TODO
当有长时间运行的事务时，可能致使purge操做来不及回收undo空间，进而致使undo空间急剧膨胀；理论上讲，若是作一次干净的shutdown，应该能够安全的将将这些undo文件删除并从新作一次初始化；也许将来的某个MySQL版本可能实现这个功能，这对于某些服务（好比按磁盘空间收费的云计算提供商）是很是有必要的功能
转载自Simple Lifemysql