MySQL事务简述（四）

purge线程用于最终完成delete和update操作。

在purge的过程中，InnoDB存储引擎收看从history list中找到第一个需要被清理的记录。清理之后，会在其所在的页中集训寻找是否存在可以被清理的记录。前面我们说过，InnoDB存储引擎允许一个页中存储多个undo信息。如果发现不能的事务undo信息，那么会返回history list中查找下一个可清理的记录。这种做法能避免大量的随机读取操作，提升purge效率。

全局动态参数innodb_purge_batch_size用来设置每次purge操作需要清理的undo page的数量。在InnoDB V1.2之前默认值20，之后默认值为300.该值越大，每次回首的undo page越多，可供重用的undo page就越多。但是值设置过大，会导致CPU和磁盘IO过于集中对undo log处理，性能反而下降。这也是MySQL数据库手册推荐普通用户无需调整该参数的原因。

全局动态参数innodb_max_purge_lag用来控制history list的长度。如果长度大于该参数，其会“延缓”DMLcaozuo .默认值为0，表示对history list不做任何限制。

“延缓”操作的时间单位是毫秒。而延缓的对象则是“行”。例如，事务更新5行数据，每行数据都会被延缓。

V1.2开始引入了全局动态参数innodb_max_purge_lag_delay，用来控制延缓的最大号描述。它能避免通过公式计算的延缓时间过大，导致其他SQL线程出现无限制的等待。

group commit功能一次fsync可以刷新确保多个事务日志被写入。这可以大大提升性能。

对于InnoDB存储引擎来说，事务提交会进行两个阶段的操作：

1）修改内存中事务对应的信息，并且将日志写入重做日志缓冲。

2）调用fsync将确保日志都从重做日志缓冲写入磁盘。

步骤2相对步骤1是一个缓慢的过程。因此，group commit可以大大提升性能。

在InnoDB V1.2之前，开启二进制日志后，InnoDB存储引擎的group commitgone能会失效，从而导致性能下降。

原因是MySQL数据库商城二进制日志写入顺序和InnoDB层的事务提交顺序一致，MySQL数据库内部使用了prepare_commit_mutex这个锁。启用这个锁后，步骤1不可以在其他事务执行步骤2时执行，从而导致了group commit失效。

MySQL V5.6采用了BLGC实现了上述问题的解决。MySQL数据库上层进行提交时，按顺序将事务房屋一个队列，队列中第一个事务为leader，其他的为follower。 BLGC步骤分为三个阶段；

1）Flush阶段，将每个事务的二进制日志写入内存

2）Sync阶段，将内存中的二进制刷新到磁盘。如果队列中有多个事务，那么一次fsync操作完成二进制的写入。

3）Commit阶段，Leader根据顺序屌用存储引擎事务的提交，InnoDB存储引擎支持group commit。

当事务仅有一个的时候，效果可能不明显，甚至比之前还差些。当提交的事务越来越多时，gourp commit效果越明显。