MySQL 5.6 新参数对binlog日志量的优化

数据库版本:5.6.*

1.row日志image类型

参数binlog_row_image 控制着这种image类型,默认为FULL(log all columns),即记录before&after images。
该参数还有两种,minimal和noblob,minimal表示只记录after更改后的值,并且如果有主键或者非空唯一索引,则只以该字段作为where条件判断;noblob同full,只是不记录blob、text列。

2.binlog日志

对于insert则没有什么好说的,我们主要重点关注一下update和delete操作。

binlog_row_image=full的情况下,对于update和delete所有的表(包含带有主键、非空唯一索引,唯一索引,没有索引)产生的binlog均一致,binlog情况如下:

  1. --建表语句
  2. CREATE TABLE `pk_test`(
  3. `id` bigint(20) NOT NULL,
  4. `username` varchar(30) NOT NULL,
  5. PRIMARY KEY (`id`)
  6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  7. insert into pk_test values (1,2);
  8. insert into pk_test values (2,2);
  9. commit;
  10. show master statusG;--记录binlog文件和pos
  11. deletefrom pk_test where id =1;
  12. update pk_test set username=‘3‘;
  13. commit;
  14. mysqlbinlog --no-defaults -v --start-position=637945822/mysqllog/3307/binlog/mysql-bin.000001| more
  15. ### DELETE FROM `baofeng`.`pk_test`
  16. ### WHERE
  17. ### @1=1
  18. ### @2=‘2‘
  19. .....
  20. ### UPDATE `baofeng`.`pk_test`
  21. ### WHERE
  22. ### @1=2
  23. ### @2=‘2‘
  24. ### SET
  25. ### @1=2
  26. ### @2=‘3‘

从上面我们可以看到,在默认为FULL的binlog_row_image下,无论表有没有主键、唯一索引,全部按照全表字段作为条件,且update会更新全部字段。

binlog_row_image=minimal的情况下:

  1. --建表语句
  2. CREATE TABLE `ui_test`(
  3. `id` bigint(20) NOT NULL,
  4. `username` varchar(30) NOT NULL,
  5. UNIQUE (`id`)
  6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  7. CREATE TABLE `ui_test_null`(
  8. `id` bigint(20),
  9. `username` varchar(30) NOT NULL,
  10. UNIQUE key (`id`)
  11. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  12. CREATE TABLE `null_test`(
  13. `id` bigint(20),
  14. `username` varchar(30) NOT NULL
  15. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  16. insert into pk_test values (1,2);
  17. insert into ui_test values (1,2);
  18. insert into ui_test_null values (1,2);
  19. insert into null_test values (1,2);
  20. commit;
  21. update pk_test set username=‘4‘;
  22. deletefrom pk_test;
  23. deletefrom ui_test;
  24. deletefrom ui_test_null;
  25. update null_test set username=‘4‘;
  26. deletefrom null_test;
  27. ### UPDATE `baofeng`.`pk_test`
  28. ### WHERE
  29. ### @1=1
  30. ### SET
  31. ### @2=‘4‘
  32. ....
  33. ### DELETE FROM `baofeng`.`pk_test`
  34. ### WHERE
  35. ### @1=1
  36. .....
  37. ### DELETE FROM `baofeng`.`ui_test`
  38. ### WHERE
  39. ### @1=1
  40. .....
  41. ### DELETE FROM `baofeng`.`ui_test_null`
  42. ### WHERE
  43. ### @1=1
  44. ### @2=‘2‘
  45. .....
  46. ### UPDATE `baofeng`.`null_test`
  47. ### WHERE
  48. ### @1=1
  49. ### @2=‘2‘
  50. ### SET
  51. ### @2=‘4‘
  52. .....
  53. ### DELETE FROM `baofeng`.`null_test`
  54. ### WHERE
  55. ### @1=1
  56. ### @2=‘2‘

从上面的例子可以看到,当binlog_row_image=minimal的情况下,where条件只有主键或不为空的唯一索引,且只会更新被改变的字段。

3.总结:

在上面的测试我们可以看到,如果采用minimal格式,将减少主键和非空唯一索引表的before值,以及减少所有表update的after未被改变的值。
从效率上来说,减少了网络传输以及加快了update的效率。

参考资料:
https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_row_image

时间: 2024-10-18 07:56:00

MySQL 5.6 新参数对binlog日志量的优化的相关文章

mysql主从复制问题之主从两端binlog日志不同步解决方案

主操作: 进入主的数据库查看状态: mysql> show master statusG; *************************** 1. row *************************** File: mysql-bin.000001 Position: 604 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.01 sec) 从操作: 进入从的数据库查看状态: mysql> show slave statusG; **

mysql做了主从,删除binlog日志

在主服务器操作: 1.查看当前主从库是用哪个binlog日志在做组从 show master status show  slave status 2.查看主库的binlog日志 show master logs 3.备份: 删除之前先做备份,避免删错,虽然耗费时间,但是换来的是意外发生导致的心脏承受不了的风险降低,很划算.. 4.删除binlog日志: purge master logs before '2019-02-03 00:00:00'      #删除2019-02-03 00:00:

Mysql数据库之Binlog日志使用总结

binlog二进制日志对于mysql数据库的重要性有多大,在此就不多说了.下面根据本人的日常操作经历,并结合网上参考资料,对binlog日志使用做一梳理: 一.binlog日志介绍1)什么是binlogbinlog日志用于记录所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句.语句以"事件"的形式保存,它描述数据更改. 2)binlog作用因为有了数据更新的binlog,所以可以用于实时备份,与master/slave主从复制结合. 3)和binl

Mysql之binlog日志说明及利用binlog日志恢复数据操作记录

众所周知,binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 废话不多说,下面是梳理的binlog日志操作解说: 一.初步了解binlogMySQL的二进制日志binlog可以说是MySQL最重要的日志,它记录了所有的DDL和DML语句(除了数据查询语句select),以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的. DDL-

MySQL binlog日志优化

mysql中日志类型有慢查询日志,二进制日志,错误日志,默认情况下,系统只打开错误日志,因为开启日志会产生较大的IO性能消耗. 一般情况下,生成系统中很少打开二进制日志(bin log),bin log日志的优化策略: mysql> show variables like '%binlog%'; +-----------------------------------------+----------------------+ | Variable_name                  

mysql binlog日志的三种模式

1.statement level模式 每一条会修改数据的sql都会记录到master的bin-log中.slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行.优点:statement level下的优点,首先就是解决了row level下的缺点,不需要记录每一行数据的变化,减少bin-log日志量,节约io,提高性能.因为他只需要记录在master上所执行的语句的细节,以及执行语句时候的上下文的信息.缺点:由于它是记录的执行语句,所以为了让这些语句在sla

MySQL 的 binlog 日志

binlog 基本认识 MySQL的二进制日志可以说是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的. 一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版).二进制有两个最重要的使用场景: 其一:MySQL Replication在Master端开启binlog,Mster把它的二进制日志传递给slaves来达到master-slave数据一致

MySQL的binlog日志<转>

binlog 基本认识 MySQL的二进制日志可以说是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的. 一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版).二进制有两个最重要的使用场景: 其一:MySQL Replication在Master端开启binlog,Mster把它的二进制日志传递给slaves来达到master-slave数据一致

mysql数据库通过bin-log日志恢复数据

binlog日志用于记录所有更新数据,当我们的数据库出现故障时,我们可以利用binlog日志来挽回. 如果mysql数据库出现问题需要重新创建binlog二进制文件. # 关闭当前的binlog日志并创建一个新日志文件,编号加1. flush logs # 查看日志,查出需要恢复的时间点 mysqlbinlog --no-defaults fangx-bin.000001 |more #恢复具体时间导成SQL语句 mysqlbinlog fangx-bin.000001 --database=f