MySQL中binlog是什么东西？
回顾上一篇的内容
在上一篇文章中，介绍了一下InnoDB引擎的架构，还说了三种redo log日志的输盘的策略
接下来，我们继续上一讲的内容来探寻一下MySQL中的binlog究竟是什么。
binlog是什么?
在上一讲里，我们了解了redo log，偏向物理性质，它记录了对哪个数据页的哪个记录进行了个什么修改，是属于InnoDB所特有的，记住，这一点希望大家牢记。
而binlog被称为归档日志，里面也记录了所作的操作，不过稍微有点不同的是偏向逻辑性的，类似于“对users表中id=10的数据做了更新操作，更新后的值是‘小明’ ”，它是属于MySQL Server自己的日志文件
所以，在提交事务的时候同，不但会把redo log写入到磁盘中去，并且也会将此次操作对应的binlog日志写入到磁盘文件中去，需要注意的是，binlog日志写入磁盘它是不经过InnoDB引擎的
和之前说的redo log刷盘策略类似，binlog日志也有刷盘策略，你可以通过下面的方式去看一下自己所使用的MySQL默认使用的是哪种方式
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
1 row in set (0.02 sec)
-
sync_binlog=0
此时你把binlog写入到磁盘的时候，其实并不是直接进入到磁盘中去，而是进入到了os cache内存缓存中
-
sync_binlog=1
当你提交事务的时候，会强制把binlog写入到磁盘中去，哪怕提交事务后宕机了，磁盘上的binlog数据也不会丢失
有了binlog后是如何完成事务的提交的？
在最后提交事务的时候，会将此次事务对应的binlog文件的文件名和路径写入到redo log中去，并且写入一个commit标记，在完成上述操作之后，事务才算是完成了提交
到这里你也许会问，为什么要加上这最后一步？
其实这一步的目的是为了保证redo log和binlog数据一致，如果说只完成了第5步或者只完成了第5 6步，只要是还没执行第7步的时候突然宕机了，那么此次事务将会被判定为事务提交失败，因为redo log里面没有commit标记
在提交事务后脏数据是如何刷入内存的呢？
当发生一次更新的时候，一旦事务提交成功，redo log日志中就会有相应的数据并且会由commit标记，不管系统是否宕机，都不会出现数据丢失的情况，很容易想到的是，磁盘中的数据也一定是早晚需要更新的，但是，是怎么更新的呢？
MySQL中有一个IO线程会专门负责将脏数据不定时地刷入到磁盘中，它会挑一个数据库压力不是那么大的时候进行这些操作
讲到这里，InnoDB的基本架构就差不多了，回顾之前讲过的内容，你有想过为什么在进行更新操作的时候不是直接修改磁盘上的文件而是通过Buffer Pool、undo log、redo log、binlog、提交事务、脏数据这么多东西来完成数据的更新？
接修改磁盘上的文件而是通过Buffer Pool、undo log、redo log、binlog、提交事务、脏数据这么多东西来完成数据的更新？
我相信大部分小伙伴都能说出来为什么，因为，我们进行更新操作的时候，对于磁盘来说是进行随机读写，如果直接对磁盘上的数据进行操作的话，速度是非常慢的，但是，将数据缓存到Buffer Pool在中然后基于内存来对其进行修改则会将速度提高非常之多，再通过写redo log、binlog日志的方式来保证数据的安全性，也许你会想，写redo log和binlog不也是向磁盘写数据吗？难道效率不会很低吗？但是，这虽然是对磁盘进行操作，但是确实顺序读写的方式，比起随机读写，磁盘的顺序读写的效率是非常之高的。因此，InnoDB引擎，通过上面这些看似繁杂的步骤，换来的却是MySQL数据库的高并发性能