其核心计算代码如下：
/*******************************************************************//** Calculate the DML delay required. @return delay in microseconds or ULINT_MAX */ static ulint trx_purge_dml_delay(void) /*=====================*/ { /* Determine how much data manipulation language (DML) statements need to be delayed in order to reduce the lagging of the purge thread. */ ulint delay = 0; /* in microseconds; default: no delay */ /* If purge lag is set (ie. > 0) then calculate the new DML delay. Note: we do a dirty read of the trx_sys_t data structure here, without holding trx_sys->mutex. */ if (srv_max_purge_lag > 0) { float ratio; ratio = float(trx_sys->rseg_history_len) / srv_max_purge_lag; if (ratio > 1.0) { /* If the history list length exceeds the srv_max_purge_lag, the data manipulation statements are delayed by at least 5000 microseconds. */ delay = (ulint) ((ratio - .5) * 10000); } if (delay > srv_max_purge_lag_delay) { delay = srv_max_purge_lag_delay; } MONITOR_SET(MONITOR_DML_PURGE_DELAY, delay); } return(delay); }但这两个参数设计有明显的两个缺陷：
缺陷1：针对total history length
假设transaction history中保留两类records，一类是是马上可以被purge的，一类是因为active transaction而不能purge的。但大多数时间，我们期望的是purgable history比较小，而不是整个history。
缺陷2：针对大小而非变化
trx_sys->rseg_history_len是一个当前history的长度，而不是一个interval时间段内undo的增长和减少的变化情况，导致trx_sys->rseg_history_len一旦超过innodb_max_purge_lag这个设定的值，就对DML产生不超过innodb_max_purge_lag_delay的时间delay，一旦低于这个值马上delay 时间就又恢复成 0。
在对系统的吞吐监控的时候，会发现系统抖动非常厉害，而不是一个平滑的曲线。类似于下图：
Purge 造成系统抖动
InnoDB purge 设计思路针对InnoDB的purge功能，可以从以下几个因素来综合考虑：
增加默认 purge thread 的个数；
测量 purgable history 长度而不是总的长度；
针对变化进行调整 delay 数值，以应对 shrinking；
基于 undo space 的大小，而不是事务的个数；
调整 undo page 在 buffer pool 中的缓存策略，类似 insert buffer；
针对 undo page 使用和 index page 不同的预读策略。
以上6条可以针对purge线程进行一些改良。
当前调优方法在当前的 MySQL 5.6 版本上，我们能做哪些调整或者调优方法，以减少transaction history增加带来的问题呢？
监控
监控trx_sys的innodb_history_list_length，为它设置报警值，及时关注和处理。
调整参数
如果你的实例是写压力比较大的话，调整innodb_purge_threads=8，增加并发purge线程数。
谨慎调整innodb_max_purge_lag和innodb_max_purge_lag_delay参数，依据现在的设计，可能你的实例的吞吐量会急剧的下降。
purge完之后再shutdown
大部分的case下，MySQL实例重启后，会发现purge的性能更差，因为undo page未命中的原因，并且是random IO请求。
如果是正常shutdown，就等purge完成再shutdown；如果是crash，就启动后等purge完成再接受业务请求。
预热
使用MySQL 5.6 提供的innodb_buffer_pool_dump_at_shutdown=on 和 innodb_buffer_pool_load_at_startup=on进行预热，把undo space page预热到buffer pool中。
在MySQL的InnoDB存储引擎中count(*)函数的优化