一、Binlog简介
官方文档参考 https://dev.mysql.com/doc/refman/5.5/en/binary-log.html
Binlog（Binary Log） 指数据库的表创建或者表数据变更的时候产生的事件event以二进制的形式存储在磁盘中，它记录了Mysql所有的DDL和DML语句（查询SELECT和SHOW除外）。除非是记录行(ROW模式)的日志记录，否则的话还包含"有可能进行变更"的语句，如：
DELETE FROM #table WHERE 0=1; (注：无效SQL)
mysqld会根据文件名、自增数据创建一系列有序的Binlog文件名，每次重启服务器、刷新日志、Binlog文件大小达到阀值时会创建一个新的有序Binlog文件。有可能Binlog文件会比max_binlog_size大，因为零界点一次使用大型事务时不会拆分成2个binlog文件。
tips: 开启Binlog服务器性能会略微降低，但是相比而言数据安全和可恢复更加重要，且Binlog是Mysql主从同步主要的方式。
二、Binlog使用场景
- 主从复制，主服务器将二进制文件发送给其他从服务器，从服务器执行这些事件进行相同的数据变更
- 某些数据恢复的场景会用到Binlog，恢复备份后执行备份后的执行Binlog，使备份数据库保持最新
- 从mysql到nosql等的数据同步(订阅Binlog并分析、执行数据)
- 实时数据分析等，大数据、搜索等
- 业务数据缓存更新
- 重要数据变化的业务通知
三、Binlog支持的数据模式
官方文档参考 https://dev.mysql.com/doc/refman/5.5/en/binary-log-formats.html
- STATEMENT 基于SQL语句的同步
- ROW 基于行数据的日志记录，指的是单表行收到的影响事件写入到Binlog中
- MIXED（ROW和STATEMENT的混合方式，默认情况下使用STATEMENT的日志记录，但在某些情况下，日志记录模式会自动切换为基于ROW）
在MySQL 5.5中，默认的二进制日志记录格式是 STATEMENT。
在MySQL 5.7中，默认的二进制日志记录格式是 ROW。
三种方式的优缺点
STATEMENT：优点数据量比较小(特别是批量SQL更新情况下)，缺点是同样的WHERE条件某些场景下主从执行的结果可能是不一致的。
ROW：记录的是一行所有的数据变更优点数据一致性略好，缺点数据量会比较大，特别是批量更新的时候 UPDATE #table WHERE 1=1
MIXED：结合和STATEMENT 和 ROW的优点
比较推荐的是ROW方式，虽然数据量会稍微大一些但同时也保持了数据的一致性，且对存储过程，事务，触发器等的支持较好(只需要关注数据层面)，MIXED个人感觉存在一定的不确定性因素。
注：MySQL 5.7 ROW多了一个参数binlog_row_image[full|minimal] ，minimal模式下行所有数据变更成了具体更新的某几列数据。这样数据量就ROW模式下的数据量可以减少很多，难怪5.7的版本会把ROW设为默认值。参考文章 https://www.cnblogs.com/gomysql/p/6155160.html
四、Binlog数据格式更改
设置系统变量的全局值 以指定更改后连接的客户端的格式
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';
单个客户端可以通过设置会话值来控制自己的语句的日志格式
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
五、MySQL Binlog数据同步原理
前面提到了mysql的主库(master)对表的变更（除查之外）都会记录到Binlog文件中，从库( slave ) 的IO Thread异步地同步Binlog文件并写入到本地的Replay文件，SQL Thread( slave ) 再抽取Replay文件中的SQL语句在从库进行执行，实现数据更新达到主从同步的目的。
Binlog是Mysql主要的主从同步方式，是一种基于stream的异步复制（并不能做到实时同步，有一定延迟）
推荐使用Row这种格式，可以很方便的反应行级别的数据变化。以下截图来自网上
