binlog的bin就暴露了他是二进制的文件，你用vi或者vim是没办法读的，得用专门的方式，比如mysqlbinlog工具。
那么binlog其实只要了解几点应该就足够了
Q：首先，binlog记录的是啥呢？
A：记录的是数据库的修改过程，注意只有真正对数据库有修改的比如增删改，才会记录。你查询不影响数据库的内容，我不会闲的没事记录你。是一种由server层记录的逻辑日志。
Q：woc哥，什么叫逻辑日志啊
A：逻辑日志可以理解为记录的是sql语句，类似于“给 ID=2 这一行的 c 字段加 1”，属于 MySQL Server 层；物理日志则是redolog的范畴了，记录内容是“在某个数据页上做了什么修改”，是数据页变更，因为数据最终是保存在数据页上的，属于 InnoDB 存储引擎层产生的。
二者侧重点不同：
-
redo log让InnoDB存储引擎拥有了崩溃恢复能力。
-
binlog保证了MySQL集群架构的数据一致性。
Q：好的，那binlog使用场景有哪些
A：最重要的就是主从复制和数据恢复。主从复制是在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。数据恢复是通过使用mysqlbinlog工具来恢复数据。其实究其本质数据恢复感觉也是为了主从复制服务的。因为二进制日志可以通过数据库的全量备份和二进制日志中保存的 增量信息 ，完成数据库的无损失恢复 。 但是，如果遇到数据量大、数据库和数据表很多（比如分库分表的应用）的场景，用二进制日志进行数据恢复，是很有挑战性的，因为起止位置不容易管理。在这种情况下，一个有效的解决办法是配置主从数据库服务器 ，甚至是一主多从的架构，把二进制日志文件的内容通过中继日志，同步到从数据库服务器中，这样就可以有效避免数据库故障导致的数据异常等问题。
这玩意说白了就是分摊风险，你没备份，服务器寄了那你公司就废了
Q：那binlog有哪些格式呢？
A：STATMENT、ROW和MIXED三种
-
STATMENT：基于SQL语句的复制（statement-based replication, SBR），每一条会修改数据的SQL语句会记录到binlog中。优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，从而提高了性能；缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp()等。
-
ROW：基于行的复制（row-based replication，RBR），不记录每条SQL语句的上下文信息，仅需记录哪条数据被修改了。优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题；缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨。
-
MIXED：基于STATMENT和ROW两种模式的混合复制（mixed-based replication，MBR），一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog。
Q：binlog怎么刷盘的
A：设定参数sync_binlog来确定binlog刷盘时间，取值范围0-N，其实从下面介绍也能看出来sync_binlog最安全的是设置是1，这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。
-
0：不去强制要求，由系统自行判断何时写入磁盘；
-
1：每次commit的时候都要将binlog写入磁盘；
-
N：每N个事务，才会将binlog写入磁盘。
