【MySql篇】一条Sql是如何执行的？

每日一句：谩惆怅 抱琵琶 闲过此秋

最近阅读了林晓斌的MySql实战45讲，深有体会，所以在此来总结一下

我们在开发过程中，Sql几乎是每天接触的语言，可大多数人，只知道语句的书写和返回结果的操作，却不知道这条语句在MySql内部的执行过程，所以今天就带大家把MySql进行拆解一下，例如以下是一条简单的查询语句

select * from T where ID=10；

一、Sql语句是如何执行的？

这里我给出了MySQL 的逻辑架构图，从中你可以清楚地看到 SQL 语句在 MySQL 的各个功能模块中的执行过程。

大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。

Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

存储引擎主要负责数据存储和提取，并且其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB

二、什么是连接器？

在工作中，我们会通过数据库工具来连接我们的数据库，而连接器就负责跟客户端建立连接、获取权限、维持和管理连接。

连接命令：mysql -hport -u$user -p

接下来就该输入我们的数据库密码，当然密码也可以跟在-p后面，但是会导致我们的密码泄露，所以生产环境一定不要这么写

随后就是MySql客户端工具，用来跟服务端建立连接。在完成TCP握手后，连接器就会开始认证你的身份，这个时候就会依据你所输入的用户名和密码。

三、缓存层

建立完成连接就可以编写Sql语句并且执行，当MySql拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。

如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。你可以看到，如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。

但是大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。

查询缓存的失效非常频繁，只要对一个表进行了更新或者sql加了一个空格，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。

好在 MySQL 也提供了这种“按需使用”的方式。你可以将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定，像下面这个语句一样：

mysql> select SQL_CACHE * from T where ID=10；

需要注意的是，MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没有这个功能了。

四、Sql分析器

Sql分析器会将我们的Sql按照空格拆分成一个个最小单元，然后通过语法库对Sql的语法进行检查分析，如果我们拼写无误，则会将我们的Sql单元转为树状结构，如图下

绿色代表关键字、红色代表变量名表名、白色则代表需进一步拆分

五、优化器

其实优化器就是提高我们的执行效率，优化器会根据分析器的树状结构生成多种Sql排列组合，然后结合Mysql的查询算法选择查询效率最快的，比如是否有索引，多个索引如何搭配，多表关联的关联顺序以及那个表为主表等，在挑选出执行效率最佳的之后，会生成一份执行计划。然后由我们的执行器执行。

如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等等，没关系，我会在后面的文章中单独展开说明优化器的内容。

六、执行器

当进入到执行器的时候，首先会进行权限判断，查看当前用户是否具有所查询表的查询权限，如果无权限，则会返回没有权限的错误，如果有权限则打开表继续执行，例如

mysql> select * from T where ID=10;

比如在表T中，ID字段没有索引，那么执行器的执行流程是这样的

调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在结果集中；

调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。

执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

至此，这个语句就执行完成了。

对于有索引的表，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的。

你会在数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。

在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟 rows_examined 并不是完全相同的。

我们后面会专门有一篇文章来讲存储引擎的内部机制，里面会有详细的说明。