MySQL binlog的几种日志录入格式以及区别

mysql binlog共有三种日志 statement row mixed

MySQL binlog日志有三种格式，分别为Statement,MiXED和ROW.

1.Statement：每一条会修改数据的sql都会记录在binlog中。

优点:

binlog文件较小

日志是包含用户执行的原始SQL,方便统计和审计

出现最早，兼容较好

缺点：

存在安全隐患，可能导致主从不一致

对一些系统函数不能准确复制或是不能复制

2.ROW不记录sql语句上下文相关信息，仅保存哪条记录被修改。

优点:

相比statement更加安全的复制格式

在某些情况下复制速度更快（SQL复杂，表有主键）

系统的特殊函数也可以复制

更少的锁

在复制时，对于更新和删除语句检查是否有主键，如果有则直接执行，如果没有，看是否有二级索引，如再没有，则全表扫描

缺点：

binlog比较大（myql5.6支持binlog_row_image）

单语句更新（删除）表的行数过多，会形成大量binlog

无法从binlog看见用户执行SQL（5.6中增加binlog_row_query_log_events记录用户的query）

3.Mixed: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。

优点:

混合使用row和statement格式，对于DDL记录statument,对于table里的行操作记录为row格式。

如果使用innodb表，事务级别使用了READ_COMMITTED or READ_UMCOMMITTED日志级别只能使用row格式。

但是使用ROW格式中DDL语句还是会记录成statement格式。

缺点:

mixed模式中，那么在以下几种情况下自动将binlog模式由SBR模式改成RBR模式。

当DML语句更新一个NDB表

当函数中包含UUID时

2个及以上auto_increment字段的表被更新时

行任何insert delayed语句时

用UDF时

视图中必须要求使用RBR时，例如创建视图使用了UUID()函数