MySQL在进行主备同步时，主库会直接把binlog拿到从库中去执行。这里就涉及到binlog的一些内容。

binlog的三种格式

binlog有三种格式，分别是statement，row和mixed。其中第三种是前两种的混合方式。

这三种日志的区别

假如说执行如下sql语句：

1	delete from t where a >= 4 and t_modified <= '2018-11-10' limit 1;

如果说binlog的格式为statement，那么binlog中会记录一个事务，事务中会执行这个sql。也就是说，该设置下，相当于把该条sql语句直接拿到从库中去执行。

如果说格式为row，那么binglog中会记录很多的内容，但是总的来说，它能够根据这些内容，去从库中直接定位到主库删除的那一条记录。就比如说，主库删除主键是1的那一行，如果记录为row格式，那么从库一定可以定位到从库中主键是1的那一行。

为什么说要定位到从库主键是1的这一行呢？

因为如果格式为statement，那么直接在从库中执行上述语句，可能会导致一些主备不一致的情况。

上述语句，如果走索引a，那么会找到第一条a >= 4的记录后，就直接删除。而走索引t_modified，则会找到第一条满足t_modified <= ‘2018-11-10’的后，就直接删除。这样的话，如果主备的索引不一致，那么就会导致删除不同的行，导致主备不一致。

而mixed就是结合了两者的优点。因为row格式需要记录太多的内容，会占用大量的空间。比如我删除10万行数据，row格式就需要10万条记录。而statement格式只需要记录一条sql，但有可能会导致主备不一致，所以采用结合的方式。由系统判断该sql是否会产生主备不一致的可能，如果会就用row记录，否则用statement。

参考

《MySQL45讲》