在写压力负载比较重的MySQL实例上，InnoDB可能积累了较长的没有被purge掉的transaction history，导致实例性能的衰减，或者空闲空间被耗尽，下面就来看看它是怎么产生的，或者有没有什么方法来减轻，避免这样的问题出现。
InnoDB purge 概要InnoDB是一个事务引擎，实现了MVCC特性，也就是在存储引擎里对行数据保存了多个版本。在对行数据进行delete或者update更改时，行数据的前映像会保留一段时间，直到可以被删除的时候。
在大部分OLTP负载情况下，前映像会在数据操作完成后的数秒钟内被删除掉，但在一些情况下，假设存在一些持续很长时间的事务需要看到数据的前映像，那么老版本的数据就会被保留相当长一段时间。
虽然MySQL 5.6版本增加了多个purge threads来加快完成老版本数据的清理工作，但在write-intensive workload情况下，不一定完全凑效。
测试案例Peter Zaitsev 使用sysbench的update进行的测试，无论是 innodb_purge_threads=1 还是8的时候，显示的transaction history快速增长的情况，如下图所示:
transaction history增长情况
下面看一下同步测试过程中purge的速度(可以通过I_S.innodb_metrics进行查询)：
InnoDB purge 情况
显示在并发 process 的过程中，purge thread 其实处在饥饿状态，待sysbench结束，purge线程满载运行清理工作。
对于这个测试结果，这里需要说明下：
对于Peter Zaitsev的测试，其实主要是为了说明transaction history的情况，如果是用sysbench进行小事务的OLTP测试，并不会产生这么明显的transaction history增长而purge thread 跟不上的情况，或者他在测试的时候，对sbtest表进行了全表查询吧，或者设置了RR级别，不过这只是猜测。
对于undo page大部分被cache在buffer pool的情况下，purge thread还是比较快的，但如果因为buffer pool的不足而导致undo page被淘汰到disk上的情况，purge操作就会被受限IO情况， 而导致跟不上。
问题分析我们来看下出现transaction history增长最常见的两种场景：
大查询
如果你在一张大表上发起一个长时间运行的查询，比如mysqldump，那么purge线程必须停下来等待查询结束，这个时候transaction undo就会累积。如果buffer pool中 free page紧张，undo page 还会被置换到disk上，加剧purge的代价。
MySQL重启
即使transaction history并没有急剧增加，但MySQL重启操作，buffer pool的重新预热，还是导致purge变成IO密集型操作。不过MySQL 5.6提供了InnoDB buffer pool的dump和reload方法，可以显著减轻purge的IO压力。
这里介绍一下如何查看buffer pool中undo page的cache情况，percona的版本上提供了I_S.innodb_rseg记录undo的分配和使用情况：
mysql> select sum(curr_size)*16/1024 undo_space_MB from innodb_rseg; +---------------+ | undo_space_MB | +---------------+ | 1688.4531 | +---------------+ 1 row in set (0.00 sec) mysql> select count(*) cnt, count(*)*16/1024 size_MB, page_type from innodb_buffer_page group by page_type; +--------+-----------+-------------------+ | cnt | size_MB | page_type | +--------+-----------+-------------------+ | 55 | 0.8594 | EXTENT_DESCRIPTOR | | 2 | 0.0313 | FILE_SPACE_HEADER | | 108 | 1.6875 | IBUF_BITMAP | | 17186 | 268.5313 | IBUF_INDEX | | 352671 | 5510.4844 | INDEX | | 69 | 1.0781 | INODE | | 128 | 2.0000 | SYSTEM | | 1 | 0.0156 | TRX_SYSTEM | | 6029 | 94.2031 | UNDO_LOG | | 16959 | 264.9844 | UNKNOWN | +--------+-----------+-------------------+ 10 rows in set (1.65 sec)从这两个information_schema下的两张表可以看到：undo space使用的总大小是1.7G，而buffer pool中cached不足100M。
InnoDB 优化方法在一定的写压力情况下，并发进行一些大查询，transaction history就会因为undo log无法purge而一直增加。
InnoDB提供了两个参数innodb_max_purge_lag，innodb_max_purge_lag_delay 来调整，即当trx_sys->rseg_history_len超过了设置的innodb_max_purge_lag，就影响DML操作最大delay不超过innodb_max_purge_lag_delay设置的时间，以microseconds来计算。