为什么要把MySQL的binlog格式修改为row

我们知道binlog有两种常用的格式，一种是statement（默认），一种是row，很多人都说建议你修改为row格式，那么是为什么呢？

首先我们需要知道它们两个之间有什么不同？ statement格式记录的我们写的SQL语句，而row格式记录的则是实际受影响的数据的变化前后值

这里举两个例子说明一下：

# 删除

statement记录的是这个删除的语句，例如：

delete from t where age>10 and modified_time<='2020-03-04'  limit 1

1

使用这个格式的binlog很可能出现下面这种问题：

1. 在主库执行这条SQL语句的时候，用的是索引age，而在备库执行这条SQL语句的时候，却使用了索引modified_time
2. 主备同步本身就存在一部分延迟，limit语句很可能受延迟的影响

而row格式记录的是实际受影响的数据是真实删除行的主键id，例如：

delete from t where id=3 and age=12 and modified_time='2020-03-05'

1

这样 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;

1
2
3
4
5
6
7
8
9

通过上面解析出来的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;

1
2
3
4
5
6
7
8
9
10
11

显然row格式记录方式按照这个binlog执行明显是正确的，也符合预期

注意：为什么这个例子强调了数据库隔离级别为读提交呢？

可重复读级别下会存在间隙锁，会话2必须等会话1释放锁后才能执行，自然也不会出问题

# 数据恢复

除了避免主备不一致外，使用row格式的binlog对恢复数据也很友好

# delete

row格式的binlog会把被删掉的行的整行 信息保存起来。所以，如果你在执行完一条delete语句以后，发现删错数据了，可以直接把binlog中记录的delete语句转成insert

# insert

row格式下，insert语句的binlog里会记录所有的字段信息，这些信息可以用来精确定位刚刚被插入的那一行。这时，你直接把insert语句转成delete语句，删除掉这被误插入的一行数据就可以了

# update

row格式下，binlog里面会记录修改前整行的数据和修改后的整行数据。所 以，如果你误执行了update语句的话，只需要把这个event前后的两行信息对调一下，再去数据库里面执行，就能恢复这个更新操作了