在MySQL中，我们经常需要打开binlog来观察用户对某一个数据库的操作，binlog中记载着对用户数据库所做的所有修改类操作，例如delete，update，insert等等。binlog一般情况下分为三种格式，分别是row格式、statement格式、mixed格式，下面就这三种格式给出一些解释:
1.Row格式
此格式不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以Row格式的日志内容会非常清楚的记录下每一行数据修改的细节。
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句或者一条alter语句，修改多条记录，则binlog中每一条修改都会有记录，每条记录都发生改变，那么该表每一条记录都会记录到日志中，这样造成binlog日志量会很大。
2.Statement格式
该格式下每一条会修改数据的sql都会记录在binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。它相比row模式能节约很多性能与日志量，具体节约的多少取决于应用的SQL情况。正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，考虑到整表删除等一些大量数据操作，ROW格式会产生大量日志，所以总体来讲statement模式会稍微好一些。
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同的结果。
3.Mixed格式
该格式是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，当statement无法完成主从复制的操作时(设计一些函数时)，则采用Row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队Row模式也被做了优化，并不是所有的修改都会以Row模式来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。
我们发现，默认情况下是使用statement模式进行的日志保存，由于测试数据库暂时没有搭建从库，主从复制时候的Row模式切换并没有测试，有兴趣的同学可以下面测试一把，就可以看到Mixed格式是在statement模式和Row模式之间进行切换的。
到底应该选用哪一种模式？
关于这三中格式的binlog，我们在使用的时候到底应该使用哪一种？我的观点如下：
如果我们的磁盘空间和服务器性能比较OK的情况下，尽量使用Row模式，因为这种模式能够最大程度的保证安全性，虽然产生的日志量很多，但是当你误删数据的时候，你就会感受到binlog给你带来的温暖。
当我们对一些不太重要的业务库(例如一些log库)进行数据主从复制的时候，尽量使用statement来执行，因为它的速度快，日志量小，而且不牵扯使用函数，是简单的数据同步。
如果有一些场景需要尽量保证性能，但是又没有十分严格的要求时，我们可以设置为Mixed格式，它可以在statement和Row之间进行切换，保证了业务的写入性能。
最后一点，在RC和RU隔离界别下，不能使用statement格式的binlog日志。
`https://cloud.tencent.com/developer/article/1533697`
