MySQL的架构设计

从上图其实我们就可以看到，我们可以通过数据库连接把要执行的SQL语句发送给MySQL数据库。假设我们的数据库服务器的连接池中的某个连接接收到了网络请求，假设就是一条SQL语句。谁负责从这个连接中去监听网络请求？谁负责从网络连接里把请求数据读取出来？

那就是网络连接必须得分配给一个线程去进行处理，由一个线程来监听请求以及读取请求数据，比如从网络连接中读取和解析出来一条我们的系统发送过去的SQL语句，如下图所示：

再来思考一下，当MySQL内部的工作线程从一个网络连接中读取出来一个SQL语句之后，此时会如何来执行这个SQL语句呢？

其实SQL是一项伟大的发明，他发明了简单易用的数据读写的语法和模型，哪怕是个产品经理，或者是运营专员，甚至是销售专员，即使他不会技术，他也能轻松学会使用SQL语句。

但如果你要去执行这个SQL语句，去完成底层数据的增删改查，那这就是一项极度复杂的任务了！

所以MySQL内部首先提供了一个组件，就是SQL接口（SQL Interface），他是一套执行SQL语句的接口，专门用于执行我们发送给MySQL的那些增删改查的SQL语句。因此MySQL的工作线程接收到SQL语句之后，就会转交给SQL接口去执行，如下图：

接着下一个问题来了，SQL接口怎么执行SQL语句呢？你直接把SQL语句交给MySQL，他能看懂和理解这些SQL语句吗？

来举一个例子，现在我们有这么一个SQL语句： select id,name,age from users where id = 1

这个SQL语句，用人脑是直接就可以处理一下，只要懂SQL语法的人，立马就知道他是什么意思，但是MySQL自己本身也是一个系统，是一个数据库管理系统，它没法直接理解这些SQL语句。所以此时有一个关键的组件要出场了，那就是查询解析器。

这个查询解析器（Parser）就是负责对SQL语句进行解析的，比如对上面那个SQL语句进行一下拆解，拆解成以下几个部分：

我们现在要从“users”表里查询数据。
查询“id”字段的值等于1的那行数据。
对查出来的那行数据要提取里面的“id,name,age”三个字段。
所谓的SQL解析，就是按照既定的SQL语法，对我们按照SQL语法规则编写的SQL语句进行解析，然后理解这个SQL语句要干什么事情，如下图所示：

通过解析器理解了SQL语句要干什么之后，接着会找查询优化器（Optimizer）来选择一个最优的查询路径。

刚才讲的那个例子好了，现在理解了一个SQL想要干这么一个事儿：要从“users”表里查询数据，查询“id”字段的值等于1的那行数据，对查出来的那行数据要提取里面的“id,name,age”三个字段。要完成这个事儿有以下几个查询路径（纯属用于大家理解的例子，不代表真实的MySQL原理，但是通过这个例子，大家肯定能理解所谓最优查询路径的意思）：

直接定位到“users”表中的“id”字段等于1的一行数据，然后查出来那行数据的“id,name,age”三个字段的值就可以了。
先把“users”表中的每一行数据的“id,name,age”三个字段的值都查出来，然后从这批数据里过滤出来“id”字段等于1的那行数据的“id,name,age”三个字段。
上面这就是一个最简单的SQL语句的两种实现路径，，要完成这个SQL语句的目标，两个路径都可以做到，但是哪一种更好呢？显然感觉上是第一种查询路径更好一些。所以查询优化器大概就是干这个的，它会针对你编写的几十行、几百行甚至上千行的复杂SQL语句生成查询路径树，然后从里面选择一条最优的查询路径出来。相当于它会告诉你，你应该按照一个什么样的步骤和顺序，去执行哪些操作，然后一步一步的把SQL语句就给完成了。具体如下图：

最后一步，就是把查询优化器选择的最优查询路径，也就是你到底应该按照一个什么样的顺序和步骤去执行这个SQL语句的计划，把这个计划交给底层的存储引擎去真正的执行。这个存储引擎是MySQL的架构设计中很有特色的一个环节。真正在执行SQL语句的时候，要不然是更新数据，要不然是查询数据，那么数据你觉得存放在哪里呢？

来思考一下，假设 MySQL 的数据有的存放在内存里，有的存放在磁盘文件里，如下图所示：

那么现在问题来了，现在已经知道一个SQL语句要如何执行了，但是怎么知道哪些数据在内存里？哪些数据在磁盘里？执行的时候是更新内存的数据？还是更新磁盘的数据？如果更新磁盘的数据，是先查询哪个磁盘文件，再更新哪个磁盘文件？

所以这个时候就需要存储引擎了，存储引擎其实就是执行SQL语句的，它会按照一定的步骤去查询内存缓存数据，更新磁盘数据，查询磁盘数据，等等，执行诸如此类的一系列的操作，如下图所示：

MySQL的架构设计中，SQL接口、SQL解析器、查询优化器其实都是通用的，它就是一套组件而已。但是存储引擎的话，它是支持各种各样的存储引擎的，比如常见的InnoDB、MyISAM、Memory等等，可以选择使用哪种存储引擎来负责具体的SQL语句执行，现在MySQL一般都是使用InnoDB存储引擎的。

存储引擎可以帮助我们去访问内存以及磁盘上的数据，那么是谁来调用存储引擎的接口呢？

其实现在还漏了一个执行器的概念，这个执行器会根据优化器选择的执行方案，去调用存储引擎的接口按照一定的顺序和步骤，就把SQL语句的逻辑给执行了。

举个例子，比如执行器可能会先调用存储引擎的一个接口，去获取“users”表中的第一行数据，然后判断一下这个数据的“id”字段的值是否等于期望的一个值，如果不是的话，那就继续调用存储引擎的接口，去获取“users”表的下一行数据。

就是基于上述的思路，执行器就会去根据我们的优化器生成的一套执行计划，然后不停的调用存储引擎的各种接口去完成SQL语句的执行计划，大致就是不停的更新或者提取一些数据出来，示意图如下：