无语了，直到今天，我才揪出MySQL磁盘消耗迅猛的“真凶”( 三 ) _MySQL

INSERT ... ON DUPLICATE KEY UPDATE这时，mysql binlog_format就会被转为row格式，这个内容也是记录在官网的其他章节：
https://dev.mysql.com/doc/refman/5.5/en/insert-on-duplicate.html
也就是说，只要业务解决了使用这种语法插入的话，磁盘空间下降迅猛的原因也能够缓解不少。我们统计发现，qps更高的其他业务中,binlog保留7天的磁盘消耗量在60GB
而该业务我们仅仅保留3天binlog，却依旧消耗了430GB的磁盘空间，这已经超过了我们整个2T磁盘空间的5分之一了。
总结通过这个案例，我们能够了解到什么情况下binlog_format会由MIXED格式转为ROW格式，以及触发的一系列并发症和解决办法，还有pt工具pt-archiver的使用。由于笔者的水平有限，编写时间也很仓促，文中难免会出现一些错误或者不准确的地方，不妥之处恳请读者批评指正。喜欢笔者的文章，右上角点一波关注，谢谢！