MySQL 整体架构一览

MySQL 在整体架构上分为 Server 层和存储引擎层。其中 Server 层，包括连接器、查询缓存、分析器、优化器、执行器等，存储过程、触发器、视图和内置函数都在这层实现。数据引擎层负责数据的存储和提取，如 InnoDB、MyISAM、Memory 等引擎。在客户端连接到 Server 层后，Server 会调用数据引擎提供的接口，进行数据的变更。

连接器

负责和客户端建立连接，获取用户权限以及维持和管理连接。

通过 show processlist; 来查询连接的状态。在用户建立连接后，即使管理员改变连接用户的权限，也不会影响到已连接的用户。默认连接时长为 8 小时，超过时间后将会被断开。

简单说下长连接：

优势：在连接时间内，客户端一直使用同一连接，避免多次连接的资源消耗。

劣势：在 MySQL 执行时，使用的内存被连接对象管理，由于长时间没有被释放，会导致系统内存溢出，被系统kill. 所以需要定期断开长连接，或执行大查询后，断开连接。MySQL 5.7 后，可以通过 mysql_rest_connection 初始化连接资源，不需要重连或者做权限验证。

查询缓存

当接受到查询请求时，会现在查询缓存中查询（key/value保存），是否执行过。没有的话，再走正常的执行流程。

但在实际情况下，查询缓存一般没有必要设置。因为在查询涉及到的表被更新时，缓存就会被清空。所以适用于静态表。在 MySQL8.0 后，查询缓存被废除。

分析器

词法分析：

如识别 select，表名，列名，判断其是否存在等。

语法分析：

判断语句是否符合 MySQL 语法。

优化器

确定索引的使用，join 表的连接顺序等，选择最优化的方案。

执行器

在具体执行语句前，会先进行权限的检查，通过后使用数据引擎提供的接口，进行查询。如果设置了慢查询，会在对应日志中看到 rows_examined 来表示扫描的行数。在一些场景下（索引），执行器调用一次，但在数据引擎中扫描了多行，所以引擎扫描的行数和 rows_examined 并不完全相同。

不预先检查权限的原因：如像触发器等情况，需要在执行器阶段才能确定权限，在优化器阶段无法验证。

MySQL 日志模块

如前面所说，MySQL 整体分为 Server 层和数据引擎层，而每层也对应了自己的日志文件。如果选用的是 InnoDB 引擎，对应的是 redo log 文件。Server 层则对应了 binlog 文件。至于为什么存在了两种日志系统，咱们往下看。

redo log

redo log 是 InnoDB 特有日志，为什么要引入 redo log 呢，想象这样一个场景，MySQL 为了保证持久性是需要把数据写入磁盘文件的。我们知道，在写入磁盘时，会进行文件的 IO，查找操作，如果每次更新操作都这样的话，整体的效率就会特别低，根本没法使用。

既然直接写入磁盘不行，解决方法就是先写进内存，在系统空闲时再更新到磁盘就可以了。但光更新内存不行，假如系统出现异常宕机和重启，内存中没有被写入磁盘的数据就会被丢掉，数据的一致性就出现问题了。这时 redo log 就发挥了作用，在更新操作发生时，InnoDb 会先写入 redo log 日志（记录了数据发生了怎么样的改变），然后更新内存，最后在适当的时间再写入磁盘。先写日志，在写磁盘的操作，就是常说到的 WAL （Write-Ahead- Logging）技术。

redo log 的出现，除了在效率上有了很大的改善，还保证了 MySQL 具有了 crash-safe 的能力，在发生异常情况下，不会丢失数据。

在具体实现上 redo log 的大小是固定的，可配置一组为 4 个文件，每个文件 1GB，更新时对四个文件进行循环写入。

write pos 记录当前写入的位置，写完就后移，当第写入第 4 个文件的末尾时，从第 0 号位置重新写入。

check point 表示当前可以擦除的位置，当数据更新到磁盘时，check point 就向后移动。

write pos 和 check point 之间的位置，就是可以记录更新操作的空间。当 write pos 追上 check point ，不在能执行新的操作，先让 check point 去写入一些数据。

可以将 innodb_flush_log_at_trx_commit 设置成 1，开启 redo log 持久化的能力。

binlog

binlog 则是 Server 层的日志，主要用于归档，在备份，主备同步，恢复数据时发挥作用，常见的日志格式有 row, mixed, statement 三种。具体的使用方法可以参见 Binlog 恢复日志这篇。

可以通过 sync_binlog=1 开启 binlog 写入磁盘。

这里对 binlog 和 redo 进行下区分：

所有者不同，binlog 是 Server 层，所有引擎都可使用。redo log 是 InnoDB 特有的。
类型不同，binlog 是逻辑日志，记录的是语句的原始逻辑（比 statement）。redo log 是物理日志，记录某个数据页被做了怎样的修改。
数据写入的方式不同，binog 日志会一直追加，而 redo log 是循环写入。
功能不同，binlog 用于归档，而 redo log 用于保证 crash-safe.

两阶段提交

一条更新语句，在 InnoDB 引擎下的更新过程如下。在更新内存后，将写入 redolog 和写入 binlog 放在一起成为一个事务最后一起写入 redo log 和 binlog 的过程就是常说的两阶段提交。用于保证当有意外情况发生时，数据的一致性。

这里假设下，如果不采用两阶段提交会发生什么？

先写 redo log 后写 binlog. 假设在写入 redo log 后，MySQL 发生异常重启，此时 binlog 没有写入。在重启后，由于 redolog 已经写入，此时数据库的内容是没有问题的。但此时，如果想要拿 binlog 进行备份或恢复，发现会少了最后一条的更新逻辑，导致数据不一致。
先写 binlog 和 redo log. binlog 写入后，MySQL 异常重启，redo log 没有写入。此时重启后，发现 redo log 没有成功写入，任务这个事务无效，而此时 binlog 却多了一条更新语句，拿去恢复后自然数据也是不一致的。

再分析下两阶段提交的过程：

在写 redo log prepare阶段奔溃，重启后，发现 redo log 没写入，发现此次事务。
如果在写 binlog 时奔溃，重启后，发现 binlog 未被写入，回滚操作
如果在写入 redo log 和 binlog 后崩溃，重启后，发现没提交，则进行 commit.

小节

在文章开始部分，说明了 MySQL 的整体架构分为 Server 层和引擎层，并简要说明了一条语句的执行过程。接着 MySQL 在 5.5 后选用 InnoDB 作为默认的引擎，就是因为比原生的 MyISAM 多了事务以及 crash-safe 的能力。

而 crash-safe 就是由 redo log 实现的。与 redo log 类似的日志文件还有 binlog，是 Server 引擎的日志，用于归档和备份数据。

最后提到了，为了保证数据的一致性，将 redo log 和 binlog 放入相同的事务中，也就是常提到的两阶段提交操作。