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

￡神魔★判官ぃ 2023-07-15 05:53 116阅读 0赞

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

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

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

### 删除 ###

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

delete from t where age>10 and modified_time<='2020-03-04'  limit 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'

这样 binlog传到备库去的时候，就肯定会删除id=3的行，不会存在主备删除不同行的问题

### 修改 ###

注意这个例子数据库隔离级别为读提交

![file][]

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前后的两行信息对调一下，再去数据库里面执行，就能恢复这个更新操作了

##### 推荐阅读 #####

1.  [Spring源码解析系列文章汇总][Spring]
2.  [SpringBoot源码解析系列文章汇总][SpringBoot]
3.  [Eureka源码解析系列文章汇总][Eureka]
4.  [SpringCloud服务调用源码解析系列文章汇总][SpringCloud]

![1][]

[file]: /images/20230528/5e43cd459472461687a4bb5d04de507d.png
[Spring]: https://mp.weixin.qq.com/s/PoQeVQ8x3DJhzswhUJl5xw
[SpringBoot]: https://mp.weixin.qq.com/s/xlBQTzbCPBuzo0nugUYvYA
[Eureka]: https://mp.weixin.qq.com/s/rqyQmjCPbLszvoFDUCxXPg
[SpringCloud]: https://mp.weixin.qq.com/s/fZAqcEcabC4MYdTOSgmEaQ
[1]: /images/20230528/68692f6faba74d57818c5013360f0535.png