因为不同库之间（主库、从库），binlog的格式，可能不同。

一、binlog格式：3种

1.1 statement格式的binlog：5.0之前

1.理论：记录的是sql语句的原文

陈述：即sql语句的原文；

主备库都去执行一模一样的sql原文？那太不安全了。

2.实例：因为主和从，因为功能定位不同，索引可能不一致

主库中：

因为当前的MySQL版本是5.7，所以人为的暂时将binlog格式改为statement：

没有显式的指定排序规则，直接删除一行；

1592warning的含义：

即表有主键，还有辅助索引。根本原因是主和从，索引，有可能是不一样的。

上面在不显式的指定排序规则情况下想删除哪一行，主库和从库，有可能是不同的。

比如从库，要数据分析，会跑一些大sql，会额外加索引

3.binlog日志，记录的是不是原文？

binlog日志里面，有很多个事件events，可以理解为一个语句一个事务。

下面，就是sql语句的原文：

4.线上，备库，尽量开只读；

在配置文件中，加一个read_only=1.

1.2 row格式的binlog：现在版本默认（推荐）

1.理论：记录的是数据行的变化，原来-->现在

ROW：原材料

• 只记录每一行数据，是怎么没变化的，是逻辑的。也不是记录InnoDB数据页，不是物理的。
• 不足：是占空间大

2.示例：更详细

主库中：

将MySQL的日志格式，改回现在的ROW：

没有显式的指定排序规则，直接删除一行；注意：此时没有出现warning

查看下binlog日志，记录的是什么：

记录的不再是sql原文，而是事件即每一行数据的变化，具体内容没有打印出来

以上，能够避免，主从复制（主备同步的时候），修改、删除等更新操作错误的情况。

1.3 mixed格式的binlog：用的少

基于上述ROW格式的binlog的不足：占空间大，所以诞生改进成了一种新的binlog格式：mixed格式。

不过，现代的数据库系统，空间很充足，不差那一点半点。

二、基于语句或行的复制

三、小结

row格式的binlog日志，是很详细，更好；