老弟啊！你都工做3年了，连binlog redo log都。。。不该该啊

前段时间，有一个读者后台问我：民工哥，我前几天去面试，就由于我简历上写着精通 MySQL，面试官就一个劲的追着我问：什么 binlog，redo log，并且仍是怎么细就怎么问，搞个人一脸懵逼。。。

当时，我也看到这话也是一脸懵逼的状态，只是呵呵一笑，回了他一句：老弟，你都工做 3 年了，连 bin log、redo log 都不知道，不该该啊。。。

因此，今天，民工哥就上次那位读者遇到的问题，分享一下这方面相关的知识，但愿对后面要去面试，或者学习这块的读者有必定帮助或参考价值。若是你感受文章对你有用，请不要吝啬你的在看与转发支持，民工哥在这先谢谢你们了。

首先，咱们先来看看一次查询/更新语句流程图

本文会将重点放在执行器<->存储引擎之间的交互。

mysql不是每次数据更改都马上写到磁盘，而是会先将修改后的结果暂存在内存中,当一段时间后，再一次性将多个修改写到磁盘上，减小磁盘io成本，同时提升操做速度。

mysql经过WAL(write-ahead logging)技术保证事务

在同一个事务中，每当数据库进行修改数据操做时，将修改结果更新到内存后，会在redo log添加一行记录记录“须要在哪一个数据页上作什么修改”，并将该记录状态置为prepare，等到commit提交事务后，会将这次事务中在redo log添加的记录的状态都置为commit状态，以后将修改落盘时，会将redo log中状态为commit的记录的修改都写入磁盘。过程以下图

redo log记录方式

redolog 的大小是固定的，在 mysql 中能够经过修改配置参数innodb\_log\_files\_in\_group 和 innodb\_log\_file\_size 配置日志文件数量和每一个日志文件大小，redolog 采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。以下图

write pos表示日志当前记录的位置，当ib\_logfile\_4写满后，会从ib\_logfile\_1从头开始记录；check point表示将日志记录的修改写进磁盘，完成数据落盘，数据落盘后checkpoint会将日志上的相关记录擦除掉，即write pos->checkpoint之间的部分是redo log空着的部分，用于记录新的记录，checkpoint->write pos之间是redo log待落盘的数据修改记录。当writepos追上checkpoint时，得先停下记录，先推进checkpoint向前移动，空出位置记录新的日志。建议收藏备查！MySQL 常见错误代码说明

有了redo log，当数据库发生宕机重启后，可经过redo log将未落盘的数据恢复，即保证已经提交的事务记录不会丢失。

有了redo log，为啥还须要binlog呢？

• 一、redo log的大小是固定的，日志上的记录修改落盘后，日志会被覆盖掉，没法用于数据回滚/数据恢复等操做。
• 二、redo log是innodb引擎层实现的，并非全部引擎都有。

基于以上，binlog必不可少

• 一、binlog是server层实现的，意味着全部引擎均可以使用binlog日志
• 二、binlog经过追加的方式写入的，可经过配置参数max\_binlog\_size设置每一个binlog文件的大小，当文件大小大于给定值后，日志会发生滚动，以后的日志记录到新的文件上。
• 三、binlog有两种记录模式，statement格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。

binlog和redo log必须保持一致，不容许出现binlog有记录但redolog没有的状况，反之亦然。以前说过在一个事务中，redolog有prepare和commit两种状态，因此，在redolog状态为prepare时记录binlog可保证两日志的记录一致，下图列出各类状况来讲明。

如今咱们再来看看整个完整的流程图

相关参数设置建议

• 一、innodb_flush_log_at_trx_commit：设置为1，表示每次事务的redolog都直接持久化到磁盘（注意是这里指的是redolog日志自己落盘），保证mysql重启后数据不丢失。
• 二、sync_binlog：设置为1，表示每次事务的binlog都直接持久化到磁盘（注意是这里指的是binlog日志自己落盘），保证mysql重启后binlog记录是完整的。

做者：会玩code
连接：https://www.jianshu.com/p/4bc...