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

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

MySQL-Server会给每一条工作线程，都分配一个bin_log_buffer，并不是放在共享缓冲区中，MySQL设计时要兼容所有引擎，直接将bin-log的缓冲区，设计在线程的工作内存中，这样就能够让所有引擎通用，并且不同线程/事务之间，由于写的都是自己工作内存中的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三种格式：

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

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

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

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

但缺陷同样很明显，比如表中有800W数据，现在我对ID