binlog_format - xiaoboluo768/qianjinliangfang GitHub Wiki
- 控制二进制日志使用哪种记录格式
- 有三个有效值（其实只有row和statement两种记录格式：mixed是row和statement混用）：mixed、row、statement
- statement：5.1版本之前都使用这种版本，日志记录中全是sql语句，主从复制的时候会将日志解析为SQL原文本，并在从库重新执行一次，这种格式的优点就是日志记录清晰易读，日至量少，对IO影响小，缺点是在某些情况下slave的日志复制会报错，比如事务提交顺序的影响。要注意：在statement格式下，RU和RC隔离级别不允许执行load data语句，在RR及其串行隔离级别下，备库在执行Load data语句时会把主库上的load data加载的临时文件拉取一份到自己的tmpdir目录下执行load data语句，执行完成后删除tempdir目录下的文件，以此来达到复制load data语句的目的。
- row：行格式，将每一行的数据改变记录到日志中(row格式中默认情况下完整的记录了before image和after image，before image代表着数据变更前的整行所有列的数据，after image记录的是数据变更之后整行所有列的数据，对于update语句，记录的是before image和after image，对于delete操作，只记录了before image，对于insert语句，记录的是after image。在5.6.x的版本中引入了一个参数binlog_row_image=full参数，控制Image中是否记录完整的列还是记录最小匹配需要的列，详见binlog_row_image参数解释部分)，而不是记录语句，这种记录格式保存在二进制日志中是加密信息，需要使用命令才能查看到内容（如使用mysqlbinlog命令的"-v --base64-output=decode-rows"参数解析binlog就可以打印可读格式），优点是能保存slave复制不出现问题，但是缺点是IO影响大，日志记录无法直接读取，日志记录量大。另外，row格式记录的是DML，对于DDL或其他管理类型的语句，记录的仍然是statement格式。如果设置了binlog_format为row，可以将innodb的事务隔离级别设置为RC，以获得更好的并发性
- mixed：目前mysql默认的日志格式，混合模式，混合了statement和row两种日志，默认情况下是使用statement，但是在一些特殊情况下自动采用row格式来记录，比如采用NDB存储引擎时、DML语句全部采用row格式、客户端使用临时表、客户端采用了不确定函数(如current_user()等，因为这些不确定函数在主从中得到的值可能不同，可能导致主从数据产生不一致。)，混合模式尽量使用两种格式的优点，避开他们的缺点。可能使用row格式的情况有：
- 1）表的存储引擎为NDB，这时对表的DML操作都会以row格式记录
- 2）使用了uuid(),user(),current_user(),found_rows(),row_count()等不确定函数
- 3）使用了insert delay语句
- 4）使用了用户自定义函数UDF
- 5）使用了临时表
- 6）使用了load data 语句
- 注意：
- row格式下不支持blackhole引擎，statement格式下不支持NDB存储引擎
- 在存储过程、函数或触发器内部，不能动态修改binlog格式，否则报错
- 如果会话当前处于基于行的复制模式并且已打开临时表，不能动态修改binlog格式，否则报错
- 不能在一个事务内部动态修改binlog格式，否则报错
- 二进制日志格式会影响以下服务器选项的行为，除非必须，否则不建议在复制架构中使用这些参数：
- 1）、--replicate-do-db
- 2）、--replicate-ignore-db
- 3）、--binlog-do-db
- 4）、--binlog-ignore-db
- 全局变量，会话变量，动态变量（修改需要有super权限），默认值为STATEMENT（但在mysql NDB cluster 7.3及其之后的版本中默认值为MIXED，因为不支持STATMENT格式，另外，在mysql5.7.7及其之后的版本中，默认为ROW格式），枚举类型。
- 有三个有效值（其实只有row和statement两种记录格式：mixed是row和statement混用）：mixed、row、statement
上一篇：enforce_gtid_consistency | 下一篇：max_binlog_size