mysql binlog生成异常_MySQL中遇到binlog 异常暴涨分析

背景

这是一个朋友遇到的问题，他的现象大概如下(MySQL5.6)：某个binlog实际大小3g左右，实际设置大小应该是1g

其中包含一个大事务，但是最后一个事务是小事务

查看大事务的XID_EVENT('commit')时间和最后一个小事务XID_EVENT('commit')时间差值近15分钟

下面是他提供的依据：mysqlbinlog -vv mysqlbinlog_file > mysqlbinlog_res.loggrep -n -B 1 "COMMIT" mysqlbinlog_res.log > file.logtar zcf file.log.tar.gz file.log通过结果可以看到大事务提交完成是binlog文件的行号是 392578997 ，往前推一个事务，提交完成后的行号是 42614752 ，期间相差3.2亿行，就是说这个事务总共写了3.2亿行的binlog大事务提交的时间是12:54:12，Xid = 4103492840 ，结束的pos值是 2915555141最后一个事务的提交时间13:08:43，Xid = 4104544654 ，结束的pos值是 2915740337

问题为什么最后事务是小事务而不是最大的那个事务，为什么大事务束后没有切换binlog呢？

为什么最后一个小事务和大事务提交时间相差了15分钟之多呢？

实际上这些问题的原因我都在我的《深入理解MySQL主从原理 32讲》中说明了，有兴趣可以关注一下文末的课程。

好了下面我们来实际分析一下。

分析

一、提交流程图

这张图是《深入理解MySQL主从原理 32讲》中第15节的截取如下，当然这个图是基于MySQL 5.7.22 画的：

好了有了这张图我们继续分析。

二、为什么大事务会包含在一个binlog里面

如图中第10步我们可以看到在flush队列的事务Event都写到binlog(不是fsync)后才会进行binlog切换的标记，言外之意就是不管有多大的事务那么都要等到写完binlog后才进行切换标记的设置。因此大事务总是在一个binlog里面。

三、为什么最后事务是小事务而不是最大的那个事务

事实上在第1