前段时间，有一个读者后盾问我：民工哥，我前几天去面试，就因为我简历上写着精通 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 呢？
- 1、redo log 的大小是固定的，日志上的记录批改落盘后，日志会被笼罩掉，无奈用于数据回滚 / 数据恢复等操作。
- 2、redo log 是 innodb 引擎层实现的，并不是所有引擎都有。
基于以上，binlog 必不可少
- 1、binlog 是 server 层实现的，意味着所有引擎都能够应用 binlog 日志
- 2、binlog 通过追加的形式写入的，可通过配置参数 max\_binlog\_size 设置每个 binlog 文件的大小，当文件大小大于给定值后，日志会产生滚动，之后的日志记录到新的文件上。
- 3、binlog 有两种记录模式，statement 格局的话是记 sql 语句，row 格局会记录行的内容，记两条，更新前和更新后都有。
binlog 和 redo log 必须保持一致，不容许呈现 binlog 有记录但 redolog 没有的状况，反之亦然。之前说过在一个事务中，redolog 有 prepare 和 commit 两种状态，所以，在 redolog 状态为 prepare 时记录 binlog 可保障两日志的记录统一，下图列出各种状况来阐明。
当初咱们再来看看整个残缺的流程图
相干参数设置倡议
- 1、innodb_flush_log_at_trx_commit：设置为 1，示意每次事务的 redolog 都间接长久化到磁盘（留神是这里指的是 redolog 日志自身落盘），保障 mysql 重启后数据不失落。
- 2、sync_binlog：设置为 1，示意每次事务的 binlog 都间接长久化到磁盘（留神是这里指的是 binlog 日志自身落盘），保障 mysql 重启后 binlog 记录是残缺的。
作者：会玩 code
链接：https://www.jianshu.com/p/4bc…