Bin-log日志也被称之为二进制日志，作用与Redo-log类似，主要是记录所有对数据库表结构变更和表数据修改的操作，对于select、show这类读操作并不会记录。bin-log是MySQL-Server级别的日志，所有引擎都能用的日志，而redo-log、undo-log都是InnoDB引擎专享的，无法跨引擎生效。bin-log也由内存日志缓冲区+本地磁盘文件两部分组成，也就是：写bin-log日志时，也会先写缓冲区，然后由后台线程去刷盘。

1. Bin-log的缓冲区

Bin-log和redo-log、undo-log的缓冲区并不同，前面分析的两种日志缓冲区，都位于InnoDB创建的共享BufferPool中，而bin_log_buffer是位于每条线程中的，关系图如下：

MySQL-Server会给每一条工作线程，都分配一个bin_log_buffer，并不是放在共享缓冲区中，MySQL设计时要兼容所有引擎，直接将bin-log的缓冲区，设计在线程的工作内存中，这样就能够让所有引擎通用，并且不同线程/事务之间，由于写的都是自己工作内存中的bin-log缓冲，因此并发执行时也不会冲突！

2. Bin-log本地日志文件的格式

bin-log的本地日志文件，采用追加写的模式，一直向文件末尾写入新的日志记录，当一个日志文件写满后，会创建一个新的bin-log日志文件，每个日志文件的命名为mysql-bin.000001、mysql-bin.000002、mysql-bin.00000x....，可以通过show binary logs;命令查看已有的bin-log日志文件。

bin-log的本地文件中，其中存储的日志记录共有Statment、Row、Mixed三种格式：

1. Statment：

每一条会对数据库产生变更的SQL语句都会记录到bin-log中，所以不会产生太大的日志量，节约空间，恢复数据时因为数据量小，磁盘IO次数少，因此性能会比较不错。同时做主备等高可用架构时，数据同步也会较小，因此比较节省带宽。但缺点也很明显，即恢复数据、主从同步数据时，有时会出现数据不一致的情况，如SQL中使用了sysdate()、now()这类函数。

例如：当执行一条插入语句时，由于对表进行了变更操作会被记录到bin-log中，当主从架构之间做数据同步时，这条插入语句同步到从机上执行，sysdate（）函数会获取机器的当前时间，显然主机和从机执行这条sql时间不同，在主机和从机的用户表中，注册时间会出现不一致。

1. Row：

这种模式就是为了解决Statment模式的缺陷，Row模式中不再记录每条造成变更的SQL语句，而是记录具体哪一个分区中的、哪一个页中的、哪一行数据被修改了。

因为不记录SQL，而是记录修改后的值，因此有个很大的好处是：当主从同步数据时，复制的是主机上的数据，因此不会出现主从数据不一致的情况。

但缺陷同样很明显，比如表中有800W数据，现在我对ID<600W的所有数据进行了修改操作，哪也就意味着会有600W条记录写入bin-log日志，这个数据量其磁盘IO、网络带宽开销会很高。

1. Mixed：

这种被称为混合模式，即Statment、Row的结合版，因为Statment模式会导致数据出现不一致，而Row模式数据量又会很大，因此Mixed模式结合了两者的优劣势，对于可以复制的SQL采用Statment模式记录，对于无法复制的SQL采用Row记录，即保留了Statment模式的数据量小，又具备Row模式的数据精准性。

3. 为什么有了Bin-log还需要Redo-log？

Redo-log、Bin-log都是记录更新数据库的操作，MySQL-Server、MyISAM是出自于官方的产品，因此MyISAM中并未设计记录变更操作的日志，记录变更操作由MySQL-Server来通过Bin-log完成。因为MyISAM不支持事务，所以MySQL-Server设计的Bin-log无法用于灾难恢复，因此InnoDB在设计时，又重新设计出Redo-log日志，可以利用该日志实现crash-safe灾难恢复能力，确保任何事务提交后数据都不会丢失。

4. Redo-log和Bin-log两者的区别

Redo-log、Bin-log两者的区别，主要可以从四个维度上来说：

• ①生效范围不同，Redo-log是InnoDB专享的，Bin-log是所有引擎通用的。
• ②写入方式不同，Redo-log是用两个文件循环写，而Bin-log是不断创建新文件追加写。
• ③文件格式不同，Redo-log中记录的都是变更后的数据，而Bin-log会记录变更SQL语句。
• ④使用场景不同，Redo-log主要实现故障情况下的数据恢复，Bin-log则用于数据灾备、同步。

5. 不小心删库后应该跑路吗？

误删了数据就要想办法恢复，可以通过日志恢复。Redo-log、Bin-log都会记录数据库的变更操作，但Bin-log会更加适合，因为Redo-log采用循环写的方式，一边写会一边擦，里面无法得到完整的数据，而Bin-log是追加写的模式，不去主动删除磁盘的日志文件，并且磁盘的空间还足够，一般Bin-log日志文件都会在本地，当你删库后，可以直接去本地找Bin-log的日志文件，然后拷贝出来一份，再打开最后一个文件，把里面删库的记录手动移除，再利用mysqlbinlog工具导出xx.SQL文件，最后执行该SQL文件即可恢复删库前的数据。

6. bin-log相关的参数

• log_bin：是否开启bin-log日志，默认ON开启，表示会记录变更DB的操作。
• log_bin_basename：设置bin-log日志的存储目录和文件名前缀，默认为./bin.0000x。
• log_bin_index：设置bin-log索引文件的存储位置，因为本地有多个日志文件，需要用索引来确定目前该操作的日志文件。
• binlog_format：指定bin-log日志记录的存储方式，可选Statment、Row、Mixed。
• max_binlog_size：设置bin-log本地单个文件的最大限制，最多只能调整到1GB。
• binlog_cache_size：设置为每条线程的工作内存，分配多大的bin-log缓冲区。
• sync_binlog：控制bin-log日志的刷盘频率。
• binlog_do_db：设置后，只会收集指定库的bin-log日志，默认所有库都会记录。

7. Redo-log的两阶段提交

是指Redo-log分两次写入，如果redo-log只写一次，那不管谁先写，都有可能造成主从同步数据时的不一致问题出现，为了解决该问题，redo-log就被设计成了两阶段提交模式，设置成两阶段提交后，整个执行过程有三处崩溃点：

• redo-log(prepare)：在写入准备状态的redo记录时宕机，事务还未提交，不会影响一致性。
• bin-log：在写bin记录时崩溃，重启后会根据redo记录中的事务ID，回滚前面已写入的数据。
• redo-log(commit)：在bin-log写入成功后，写redo(commit)记录时崩溃，因为bin-log中已经写入成功了，所以从机也可以同步数据，因此重启时直接再次提交事务，写入一条redo(commit)记录即可。

通过这种两阶段提交的方案，就能够确保redo-log、bin-log两者的日志数据是相同的，bin-log中有的主机再恢复，如果bin-log没有则直接回滚主机上写入的数据，确保整个数据库系统的数据一致性。

因为记录日志时，MySQL写入的是二进制数据，而并非字符数据，也就意味着直接用cat/vim这类工具是无法打开的，必须要通过MySQL提供的mysqlbinlog工具解析查看，所以bin-log也称为二进制日志。