Binlog是MySQL高可用、备份的基础。绝大多数的场景下，都需要开启Binlog。因此AliSQL 团队对Binlog的性能优化方面做了很多的探索和尝试，希望在开启Binlog时，也能够有很好 的性能提升。

如上图所示，在事务的提交过程中有两次存储IO的写操作。第一次是Redo的写操作，将事务 的Prepare状态持久化。第二次是Binlog的写操作，将事务的Binlog Events持久化。这是一 个精心设计的过程，2次IO操作，保证了Binlog和引擎中数据的一致性。但是在事务的提交 过程中，存储IO的写操作是一个比较慢的过程，尤其对于网络存储更是如此。2次IO写操作 对事务的提交性能有很大的影响。

那么有没有办法在减少1次IO的情况下，又能保证Binlog和数据的一致性呢？答案是有的， 而且无论去掉Redo的Sync还是Binlog的Sync都可以保证Binlog和数据的一致性。

最终我们选择去掉Binlog Sync。这个方案中需要将Binlog写入InnoDB Redo Log。因此称作 Binlog In Redo。之所以选择这个方案，除了性能更好之外，也是因为这个设计对Polar DB 也非常重要。

• 当事务提交时，将事务的Binlog Events写入到Redo中，然后将Redo持久化。而Binlog文件 则采用异步的方式，用单独的线程周期性的持久化到存储中。因此事务的提交过程中，减少 了一次IO。

• 这个设计从数据保护上保持了双1配置的含义，从性能上则去掉了Binlog的刷盘。由于减少 了一次IO操作，性能得到了提升，RT变的更小。Binlog文件刷盘次数的减少，极大地减少了 文件系统因文件长度实时变化带来的fsync压力，也提升了文件系统的性能。

测试环境

RDS规格： 32Core， 64G Ram， ESSD存储。

测试工具： sysbench

oltp_insert

olpt_update_non_index和oltp_insert都属于单语句事务。oltp_write_only是多语句事务， 包含2个UPDATE,一个DELETE，一个INSERT。olpt_update_non_index和oltp_insert的事务提 交次数比oltp_write_only要多很多，所以olpt_update_non_index和oltp_insert的性能提 升比oltp_write_only更为明显。

Binlog Fsync 次数对比

开起binlog in redo功能时，Binlog fsync的次数要少非常多。

Binlog In Redo 已经在RDS 8.0 20200430版本中发布，欢迎使用。