先从redo.log讲起吧，redo.log是InnoDB存储引擎独有的，是物理日志，它让MySQL有了崩溃恢复的能力，比如MySQL挂了或者宕机了，重启时，InnoDB会使用redo.log恢复数据，保证数据的完整性。嗯。。然后的话，先说一下Buffer Pool，MySQL查询时是以页为单位的返回的，我们要查询一条数据，就得先从硬盘中加载数据页到Buffer Pool中，然后就是我们后续进行更新、删除、添加时，如果命中索引对应的那个数据页时，那么就直接在这个Buffer Pool保存更改就行，而不需要再去硬盘中加载数据页到内存中，减少磁盘IO开销。当我们要查询时，再把数据页从硬盘加载到内存，把Buffer Pool中的更改加上去，就是最新的数据了。我刚才说的其实只是Buffer Pool中的change buffer，它里面还有个和redo.log相关的，叫做redo log buffer，当我们对“在某个数据页上做了什么修改”时，就会记录到这个redo log buffer中（Mysql特有的内存），再在合适的时机刷盘到硬盘中。这个时机的话，可以自己设置的，一种是每次事务提交都不进行刷盘操作，当然不代表就不刷盘了，因为InnoDB有个后台线程，每隔1秒就刷盘一次，所以这样MySQL挂了或宕机会有1秒的数据丢失。还有一种是每次事务提交都进行刷盘，这也是默认值，这样的话，无论怎样都不会有数据的丢失。最后还有一种就是每次事务提交就提交到page cache，就是加载到文件缓冲当中，当MySQL挂了再重启的时候，内存中的数据还在，所以还可以恢复，但是如果是服务器宕机了，就会丢失数据。redo日志我理解的大概就这些，提供了数据库崩溃恢复的能力。

    binlog日志它是存在于server层的，是一种二进制日志。我们数据库的数据备份、主从复制等都需要依靠它来同步数据，保证数据一致性。它的格式有三种，statement、row、mixed，statement的话是记录sql原句，这样的话，比如sql中调用一个函数now()来求当前时间，那么之后的数据和之前插入的数据的时间就是不一样的了，而row的话就是记录具体的数据，就不会出现数据不一致的情况，而mixed的话，就是数据库自己分析哪些会导致不一致，有的话就用row，没有的话就用statement。然后binlog的写入的话，相对来说比较简单，它的刷盘有三种情况，一种是每次事务提交都只写入到文件系统缓存page cache中，并没有持久化至硬盘，由系统判断什么时候刷盘，这是binlog默认的选项。第二种是每次事务提交都刷盘。还有一种折中的方法，可以设置达到n个事务提交才刷盘，但宕机时，会丢失n个事务。