【MySQL技术内幕】49-事务的实现之group commit

作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题

代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

若事务为非只读事务,则每次事务提交时需要进行一次 fsync操作,以此保证重做日志都已经写入磁盘。当数据库发生宕机时,可以通过重做日志进行恢复。虽然固态硬盘的出现提高了磁盘的性能,然而磁盘的fsync性能是有限的。为了提高磁盘 fsync的效率,当前数据库都提供了 group commit的功能,即一次 fsync可以刷新确保多个事务日志被写入文件。对于 InnoDB存储引擎来说,事务提交时会进行两个阶段的操作:

1. 修改内存中事务对应的信息,并且将日志写入重做日志缓冲
2. 调用 fsync将确保日志都从重做日志缓冲写入磁盘。

步骤2)相对步骤1)是一个较慢的过程,这是因为存储引擎需要与磁盘打交道。但当有事务进行这个过程时,其他事务可以进行步骤1)的操作,正在提交的事物完成提交操作后,再次进行步骤2)时,可以将多个事务的重做日志通过一次fsync刷新到磁盘,这样就大大地减少了磁盘的压力,从而提高了数据库的整体性能。对于写入或更新较为频繁的操作, group commit的效果尤为明显。
然而在 InnoDB1.2版本之前,在开启二进制日志后, InnodB存储引擎的 group commit功能会失效,从而导致性能的下降。并且在线环境多使用 replication环境,因此二进制日志的选项基本都为开启状态,因此这个问题尤为显著。
导致这个问题的原因是在开启二进制日志后,为了保证存储引擎层中的事务和二进制日志的一致性,二者之间使用了两阶段事务,其步骤如下:

1. 当事务提交时 InnoDB存储引擎进