binlog记录的三种格式row statement mixed
官方文档 https://dev.mysql.com/doc/refman/5.7/en/binary-log-setting.html
Row 记录写操作发生后改变的行
优点：
row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解
能够完全保证主从数据的一致性，不会出现因为在SQL中使用MySQL自带的函数导致数据不一致的现象
缺点：
会消耗比较大的磁盘空间和磁盘IO
因为ROW格式是基于每行进行修改的，若是在master执行一个update修改5000行数据，那么slave就会执行5000次修改数据操作，那么这就会带来更严重的主从延迟
statement:记录发生写操作的查询
优点：
就是消耗较少的磁盘存储和IO
缺点：
在主从复制时，跨库操作会丢数据
可能会导致数据不一致，并且在做基于binlog恢复的时候可能会出现数据不一致的现象
Mixed 根据情况两者皆有
- 修改binlog格式后，需要重启一下slave操作
- 新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果SQL语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。
针对系统库 mysql 里面的表发生变化时的处理准则如下：
1. 如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 binlog_format 的设定而记录
1. 如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何 都采用 SBR 模式记录
1. blockhole引擎不支持row格式，ndb引擎不支持statement格式
