移除MySQL Binlog？亲，你根本不懂MySQL呐~~~
破产码农
IT圈最会讲故事的网红 · 南山彭于晏
最近在公司内部分享的时候，有同学提出：MySQL是不是应该废弃二进制日志，因为MySQL内部存在二进制日志和引擎层的重做日志两种日志，移除二进制日志，可以进一步提升数据库的写入性能。
现有的复制也可以改为类似Oracle的重做日志同步，只要有意愿，MGR也能改成基于重做日志。
诚然，不少公司已经在这么做了，比如阿里云的PolarDB。但这真的是个好的idea么？
在IMG群中，姜老师多次强调PolarDB不是未来，只能应用于对数据库整体要求并不高的场景。传统数据库的发展，PolarDB并不是未来的形态。
Amazon Aurora已经make huge money了？我也不信，换标准MySQL一样也可以有途径节省存储成本，从而达到赚钱的效果。
真正赚钱的原因是因为各公司都在使用MySQL数据库，云上是标配。
因此，换了区区是MySQL产品经理，直接就将移除二进制日志的提议否决掉。完全不懂数据库，不懂MySQL成功的关键因素是什么。
MySQL Binlog是成功关键
MySQL的成功因素是什么？是因为Monty代码写得好？不是的，Monty的代码甚至大部分都是抄袭的。优化器的代码，惨不忍睹，被人吐槽至今。MySQL 8.0重构后，才有了些些未来能有起飞的空间。
InnoDB存储引擎真的强，甚至有单挑Oracle数据库的潜力，代码行云流水，势如破竹。MySQL 5.5版本前，默认存储引擎是事务功能不支持，MVVCC也不支持，行锁也不支持的MyISAM。大部分公司用的也是MyISAM引擎，甚至现在都有不少业务数据跑在MyISAM引擎上。
因此，纵观MySQL发展的历史正文，其基于二进制日志的灵活复制机制，是MySQL大获成功的本质原因。PostgreSQL完败于MySQL，主要因素也是如此。PG直到非常后面的版本才有了官方的同步机制，之前的第三方机制，并不能让用户满意。
MySQL诞生至今已25年，现在的MySQL是否能考虑移除二进制日志了呢？
从Oracle公司收购MySQL数据库伊始，就将InnoDB作为后续唯一持续开发的存储引擎。MySQL 8.0已移除MyISAM引擎，并将所有的数据字典表从MyISAM引擎更换为了InnoDB存储引擎。
看似上述操作都在为移除二进制日志铺路做准备，然而二进制日志依然是MySQL成功的因素：二进制日志，方便异构系统之间数据的交互。
MySQL二进制日志完整保存了一条记录的前项和后项记录，可以方便的写个DTS服务，将MySQL数据以准实时的方式同步到其他数据库系统，比如ES、HBase、Redis、Hive、Spark等，这个特性至关重要。
Linux的成功不是Linux本身的成功，是开源生态的成功。同样，MySQL的成功，并不是MySQL自己的成功，而是整个开源数据库生态的成功。MySQL + Hive类似这样的组合，才能击败Oracle、Sybase、DB2、Microsoft SQL Server这样的商业数据库产品。
回到性能的角度，在MySQL 5.6版本修复组提交性能bug后，内部两阶段提交带来的性能开销已经非常非常小。其次，硬件的发展是飞速，特别是SSD这样的设备，目前数据库瓶颈已经不在存储，而是关系型数据库落后的存储结构设计与先进的存储设备之间的矛盾。
MySQL 8.0版本对SSD做了非常多的优化和适配，通过目前的测试结果来看，已然能充分发挥出SSD的潜力。
这种针对硬件的优化是很常见的，如PS4新主机刚推出时，游戏并不能充分发挥新时代游戏机的所有性能。游戏引擎要根据主机硬件特性，不断调优，后期推出的游戏才能完全发挥出主机的性能。
因此PS新主机发布时，通常有GT（Gran Turismo）这款游戏护航。因为这是Sony自己研发的游戏，相对其他游戏工作室，更能充分发挥新主机的性能。否则，可能初始PS4游戏和PS3并无太大感官上的区别。
回到MySQL二进制日志的讨论，若去掉二进制日志功能，MySQL就丧失了生态优势，所有事情都需自己完成。因此，可以看到PolarDB在做分布式优化器特性，以此弥补MySQL在OLAP方面的短板。
但这条路太难走。MySQL优化器本就在重构过程中，很多历史遗留问题还未彻底解决，这时在错误的东西上去做优化，结果很难说是正确。而自己先去做优化器的代价，需要投入的精力和产出的价值之间，即便阿里，选择都太痛苦。
此外，官方若要移除二进制日志，意味着复制模块，MGR模块，全部重构。之前互联网上已跑着的高可用架构，需要大幅调整。更不用说DBA学习成本的提升。
总之，从产品角度看，移除二进制日志，这是条不归路。
二进制日志优化乱谈
二进制日志不能去除，他是目前复制的基石，也是打通其他平台的数据粘合剂。因此，二进制日志真正的发展，应该是保留。但为了解除二进制日志和重做日志带来的两阶段事务引入的性能瓶颈，可以将二进制日志优化为保存日志到InnoDB层。
一种简单的做法，事务提交时，在重做日志中写入二进制日志缓冲的信息。这样的话，可以做到只写1个文件，从而避免使用XA事务保证写2个文件的一致性问题。
但是呢，这需要对重做日志进行比较大的重构工作，然后再封装一封对外的复制接口。
性能真正的提升效果呢？因为组提交优化的存在，fsync对I/O的影响其实已经不大，真正的去除二进制日志的收益，个人预估非常有限。
对有手动能力的内核同学来说，可以考虑新增一个重做日志类型，然后在函数trx_commit流程中，将上层的二进制日志缓存写入到重做日志来看看性能效果。
总结
讲真的，移除MySQL二进制日志真的不是一个好主意，收益非常非常有限。最多只是省了fsync的性能开销。
由于数据依然要同步到其他平台，前后项的二进制日志依然需要，除非自己把MySQL打造成一个封闭的平台。但这么做，却又自己把自己玩死了。
当今世界，合作共赢是趋势，一家通吃，只能独木难支。因此，美国发起的贸易战，是旧时代思维观念，不符合整个人类命运体的发展，注定将最终失败。