我们知道binlog有两种常用的格式，一种是statement（默认），一种是row，很多人都说建议你修改为row格式，那么是为什么呢？
首先我们需要知道它们两个之间有什么不同？
statement格式记录的我们写的SQL语句，而row格式记录的则是实际受影响的数据的变化前后值
这里举两个例子说明一下：
删除
statement记录的是这个删除的语句，例如：
delete from t where age>10 and modified_time<='2020-03-04' limit 1
使用这个格式的binlog很可能出现下面这种问题：
- 在主库执行这条SQL语句的时候，用的是索引age，而在备库执行这条SQL语句的时候，却使用了索引modified_time
- 主备同步本身就存在一部分延迟，limit语句很可能受延迟的影响
而row格式记录的是实际受影响的数据是真实删除行的主键id，例如：
delete from t where id=3 and age=12 and modified_time='2020-03-05'
这样 binlog传到备库去的时候，就肯定会删除id=3的行，不会存在主备删除不同行的问题
修改
注意这个例子数据库隔离级别为读提交
statment格式记录的binlog可能会是这样：
会话二：
begin；
update t set d=5 where id=0;
commit;
会话一：
begin；
update t set d=100 where d=5;
commit;
通过上面解析出来的binlog执行就有问题了，最终结果是2行数据d变成了100，明显与期望不一致。
如果是row格式，那么伪日志记录如下：
会话二：
begin；
update t where id=0 and c=0 and d=0
set id=0,c=0,d=5
commit;
会话一：
begin；
update t where id=5 and c=5 andd=5
set id=5,c=5,d=100
commit;
显然row格式记录方式按照这个binlog执行明显是正确的，也符合预期
注意：为什么这个例子强调了数据库隔离级别为读提交呢？
可重复读级别下会存在间隙锁，会话2必须等会话1释放锁后才能执行，自然也不会出问题
数据恢复
除了避免主备不一致外，使用row格式的binlog对恢复数据也很友好
delete
row格式的binlog会把被删掉的行的整行 信息保存起来。所以，如果你在执行完一条delete语句以后，发现删错数据了，可以直接把binlog中记录的delete语句转成insert
insert
row格式下，insert语句的binlog里会记录所有的字段信息，这些信息可以用来精确定位刚刚被插入的那一行。这时，你直接把insert语句转成delete语句，删除掉这被误插入的一行数据就可以了
update
row格式下，binlog里面会记录修改前整行的数据和修改后的整行数据。所 以，如果你误执行了update语句的话，只需要把这个event前后的两行信息对调一下，再去数据库里面执行，就能恢复这个更新操作了
推荐阅读
