MySQL：Binlog大于4G的考虑
作者简介：高鹏，笔名八怪。《深入理解MySQL主从原理》图书作者，同时运营个人公众号“MySQL学习”，持续分享遇到的有趣case以及代码解析！
我们知道一个事务的binlog一定在一个binlog里面，其实一个group commit的事务都应该在一个binlog里面，那么很可能这个binlog的大小会大于4G。可以参考这篇文章：https://www.jianshu.com/p/10082cb72c42 截取部分解析如下：
事实上在第10步中我们只是设置了切换标记而已，实际的切换会等到本事务所在的commit队列都提交完成后才会进行binlog的切换，具体就是参考第28步。
在这个期间会有2个原因导致大事务并不是binlog的最后一个事务：
对于flush队列而言，大事务可能包含在队列中的某个位置，队列后面可能包含小事务。
对于sync队列而言，大事务的提交会在sync阶段耗费很多时间，如果我们假设为30秒，那么在这30秒内其他新的事务是可以进入新的flush队列的，也能够进行写binlog（不是fsync）的操作。
因此线上有压力的库，binlog的最后一个事务通常不是大事务。
