我所了解的MySQL之一：根基架构
3. 日志模块
前面所说的施行流程主如果描写查询语句，假如是更新语句还触及到 MySQL 的日志模块。
从客户端到施行器的之间的逻辑查询语句和更新语句是雷同的，只是在到施行器这一层的时候，更新语句会和 MySQL 的日志模块发生交互，这是查询语句和更新语句不一样的地方。
3.1 物理日志 redo log
3.1.1 redo log 中记载的内容
关于 InnoDB 储备引擎来说，它有一个特有的日志模块——物理日志（重做日志）redo log，它是 InnoDB 储备引擎的日志，它所记载的是数据页的物理修改。
举个例子，此刻有一张 user 表，有一条主键 id=1，age=18 的数据，然后会员提交了下面这条 SQL，施行器预备施行。
update user set age=age+1 where id=1;复制代码
关于这条 SQL，在 redo log 中记载的内容大致是：将 user 表中主键 id=1 行的 age 字段值修改为19。
3.1.2 WAL
MySQL 的更新耐久化逻辑使用到了 WAL(Write-Ahead Logging，写前日志记载) 的思想：先写日志，再写磁盘。
需要留意的是这里的写日志也是写到磁盘中，但由于日志是次序写入的，所以速度很快。而假如没有 redo log，直接更新磁盘中的数据，那么第一需要寻到那笔记录，然后再把新的值更新进入，由于查询和读写I/O，就相对会慢一些。
最后，当 InnoDB 引擎余暇的时候，它会去施行 redo log 中的逻辑，将数据耐久化到磁盘中。
3.1.3 redo log 日志文件
redo log 日志文件大小是牢固的，我把它懂得为一个轮回链表，链表的每个节点都可以存置日志，在这个链表中有两个指针：write（黑） 和 read（白）。
最开端这两个指针都指向统一个节点，且节点日志元素都为空，表示此时 redo log 为空。当会员开端提交更新语句，write 节点开端往前移动，假设移动到3的位置。而此时的状况就是 redo log 中有1-3这三个日志元素需要被耐久化到磁盘中，当 InnoDB 余暇时，read 指针往前移动，就代表着将 redo log 耐久化到磁盘。
但这里有一种非凡状况，就是 InnoDB 不断没有余暇，write 指针不断在写入日志，直到它写到5的位置，再往前写又回到了最开端1的位置（也就是上图的位置，但不一样的是链表节点中都存在日志数据）。
此时发明1的位置已经有日志数据了，同时 read 指针也在。那么这时候 write 指针就会暂停写入，InnoDB 引擎开端催动 read 指针移动，把 redo log 清空掉一部分之后再让 write 指针写入日志文件。
3.1.4 redo log 的作用
我们已经知道，redo log 中记载的是数据页的物理修改，所以 redo log 能够包管在数据库发生非常重新启动时，记载尚未写入磁盘，但是在重新启动后可以通过 redo log 来“redo”，从而不会发生记载丧失的状况，包管了事务的耐久性。
这一能力也被称作 crash-safe。
3.2 归档日志 bin log
前面说到 redo log 是 InnoDB 特有的日志，而 bin log 则是属于 MySQL Server 层的日志，在默许的 Statement Level 下它记载的是更新语句的原始逻辑，即 SQL 本身。
别的需要留意的是：
- bin log 的日志文件大小并不牢固，它是“追加写入”的模式，写完一个文件后会切换到下一个文件写入。
- bin log 没有 crash-safe 的能力。
- bin log 是在事务终究提交前写入的，而 redo log 是在事务施行中不竭写入的。
3.2.1 bin log 的作用
与 redo log 不一样的是，bin log 常用于复原数据，比方说主从复制，从节点按照父节点的 bin log 来停止数据同步，实现主从同步。
3.3 两阶段提交
为了让 redo log 和 bin log 的状态保持一致，MySQL 使用两阶段提交的方式来写入 redo log 日志。
在施行器调取 InnoDB 引擎的接口将写入更新数据时，InnoDB 引擎会将本次更新记载到 redo log 中，同时将 redo log 的状态标志为 prepare，表示可以提交事务。
随后施行器生成本次操纵的 bin log 数据，并写入 bin log 的日志文件中。
最后施行器调取 InnoDB 的提交事务接口，储备引擎把刚写入的 redo log 记载状态修改为 commit，本次更新完毕。
在这个历程中有三个步骤 add redo log and mark as prepare -> add bin log -> commit，即：
- 写入 redo log 日志并标志为 prepare
- 写入 bin log
- 提交事务
假如在第二个步骤，也就是写入 bin log 此前系统崩溃或重新启动，启动后由于 bin log 中没有记载，会将 redo log 中的记载回滚至施行本次更新语句前。
假如在第三个步骤前，也就是提交此前系统崩溃或重新启动，即使没有 commit 但是知足 redo log 中记载为 prepare 状态并且 bin log 中也有完全记载，在重新启动后会主动 commit，并不会回滚。
4. 小结
本文主要介绍 MySQL 的根基架构乃至各个组成部分的功效，最后介绍了 MySQL Server 层的 bin log 和 InnoDB 特有的 redo log 这两种日志模块。
5. 数往知来
以下的几个问题是对本文所描写内容的发问，稳固知识，正所谓“温故而知新，可认为师矣”。
- 假如查询语句中字段不存在、字段有歧义、关键字拼写错误，是由哪个部分报错？
- 假如会员对表没有查询权限，是哪个部分报错？
- 为什么 MySQL 的查询缓存会无效？
- 一条 select 查询语句是怎样施行的？
- MySQL 常用的储备引擎是什么？
- MySQL 的日志模块是什么？离别起到什么作用？
- redo log 写满了如何办？
- 怎样懂得 redo log 的两阶段提交？
redo log 和 bin log 的不同？
