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()函数

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值