MySQL—一条查询SQL语句的完整执行流程

最新推荐文章于 2024-05-03 18:15:47 发布

随机的未知

最新推荐文章于 2024-05-03 18:15:47 发布

阅读量1.8k

点赞数 51

分类专栏： MySQL 文章标签： mysql 数据库

本文链接：https://blog.csdn.net/qq_41243472/article/details/138105215

版权

MySQL 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

MySQL—一条查询SQL语句的完整执行流程

表结构和数据如下：

表结构和数据

我们分析的sql语句如下：

select tb_id,tb_name,tb_address from tb_user where tb_id = 66;

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

Server层

包括:连接器、查询缓存、分析器、优化器、执行器等
涵盖MySQL的大多数核心服务功能
所有的内置函数(如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现
- 比如:存储过程、触发器、视图等
存储引擎层:
- 负责数据的存储和提取
- 可插拔式存储引擎:InnoDB、MyISAM、Memory等
  - 最常用存储引擎是InhoDB
  - 从MySQL 5.5版本开始，默认存储引擎是lnnoDB

SQL执行流程

第一步:连接到数据库

首先会连接到这个数据库上，这时候接待我们的就是连接器。

mysql -uroot -p

连接数据库

连接完成后，如果没有后续的动作，这个连接就处于空闲状态。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数wait_timeout控制的，默认值是8小时。

show processlist;

其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接。

连接状态

第二步:查缓存

MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以key-value对的形式，被直接缓存在内存中。key是查询的语句hash之后的值，value是查询的结果。

如果查询语句在缓存中，会被直接返回给客户端。
如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。

如果查询命中缓存，MySQL不需要执行后面的复杂操作就可以直接返回结果，效率会很高!但是不建议使用MySQL的内置缓存功能。

查询缓存

查询缓存默认是关闭的状态。

# 查看是否开启缓存
show variables like 'query_cache_type';
# 查看缓存的命中次数：
show status like 'qcache_hits';

查询缓存相关内容

开启缓存

在/etc/my.cnf文件中修改“query_cache_type”参数

值为`0或OFF`会禁止使用缓存。
值为`1或ON`将启用缓存，但以`SELECT SQL_NO_CACHE`开头的语句除外。
值为`2或DEMAND`时，只缓存以`SELECT SQL_CACHE`开头的语句。

清空查询缓存

可以使用下面三个SQL来清理查询缓存：

# 清理查询缓存内存碎片。
FLUSH QUERY CACHE; 
# 从查询缓存中移出所有查询。
RESET QUERY CACHE;
# 关闭所有打开的表，同时该操作将会清空查询缓存中的内容。
FLUSH TABLES;

清空查询缓存

不建议使用MySQL的查询缓存

因为查询缓存往往弊大于利

成本高:查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。
命中率不高:对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。
功能并不如专业的缓存工具更好:redis、memcache、ehcache…
MySQL提供了按需使用的方式，我们可以将参数query_cache_type设置成DEMAND，这样对于默认的SQL语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用SQL_CACHE显式指定，像下面这个语句一样:
```
select sql_cache * from tb_user where tb_id = 16;
```

MySQL 8.0 版本直接将查询缓存的整块功能删掉了。

第三步:分析SQL语句

如果查询缓存没有命中，接下来就需要进入正式的查询阶段了。客户端程序发送过来的请求，实际上只是一个字符串而已，所以MySQL服务器程序首先需要对这个字符串做分析，判断请求的语法是否正确，然后从字符串中将要查询的表、列和各种查询条件都提取出来，本质上是对一个SQL语句编译的过程，涉及词法解析、语法分析、预处理器等。

词法分析:词法分析就是把一个完整的SQL语句分割成一个个的字符串；
语法分析:语法分析器根据词法分析的结果做语法检查，判断你输入的SQL语句是否满足MySQL语法；
预处理器:预处理器则会进一步去检查解析树是否合法，比如表名是否存在，语句中表的列是否存在等等，在这一步MySQL会检验用户是否有表的操作权限。

词法分析

比如我们前文所提到的sql语句，分割前为：

select tb_id,tb_name,tb_address from tb_user where tb_id = 66;

分割后为

select,
tb_id,
tb_name,
tb_address,
from,
tb_user,
where,
tb_id,
=,
66
;

MySQL同时需要识别出这个SQL语句的字符串分别是什么，代表什么。

把select关键字识别出来，是查询语句；
把tb_user识别出来是表名tb_user；
…

语法分析

如果语法正确就会根据MySQL语法规则与SQL语句生成一个数据结构——解析树；

如果我们把from写成form；

会报出如下错误：

报出错误

我们前面的SQL语句，生成解析树如下：

select tb_id,tb_name,tb_address from tb_user where tb_id = 66;

解析树

预处理器

预处理器会进一步去检查解析树是否合法，比如表名是否存在，语句中表的列是否存在等等，在这一步MySQL会检验用户是否有表的操作权限。

预处理之后会得到一个新的解析树，然后调用对应执行模块。

第四步:优化SQL语句

优化器顾名思义就是对查询进行优化。作用是根据解析树生成不同的执行计划，然后选择最优的执行计划。

MySQL里面使用的是基于成本模型的优化器，哪种执行计划Explain执行时成本最小就用哪种。而且它是io_cost和cpu_cost的开销总和，它通常也是我们评价一个查询的执行效率的一个常用指标。

show status like 'Last_query_cost';

查看上次查询成本开销

查看上次查询成本开销，默认值是0

优化器可以做的优化有:

当有多个索引可用的时候，决定使用哪个索引；
在一个语句有多表关联（join）的时候，决定各个表的连接顺序，以哪个表为基准表。

优化器最多是辅助，作用很有限，我们的SQL语句不能依赖于MySQL的优化器去调优！

第五步:执行SQL语句

判断执行权限

开始执行的时候，要先判断一下对这表tb_user有没有执行查询的权限，如果没有权限，就会返回无权限的错误。

比如：我们新建一个用户hello_user，只有库sjdwz_test表tab_test的查询权限，没有表tb_user的查询权限。

CREATE USER `hello_user`@`localhost` IDENTIFIED BY '7654321@Hello';
GRANT Select ON TABLE `sjdwz_test`.`tab_test` TO `hello_user`@`localhost`;

使用这个用户hello_user连接mysql，

mysql -uhello_user -p

执行下面的查询语句，就会返回没有权限的错误

select tb_id,tb_name,tb_address from tb_user where tb_id = 66;

报出无权限

调用存储引擎接口查询

如果有权限，就使用指定的存储引擎打开表开始查询。执行器会根据表的引擎定义，去使用这个引擎提供的查询接口提取数据。

tb_id是主键执行流程:
- 调用InnoDB引擎接口，从主键索引中检索c_id=14的记录。
- 主键索引等值查询只会查询出一条记录，直接将该记录返回客户端。
- 至此，这个语句就执行完成了。
tb_id不是主键执行流程:全表扫描
- 调用InnoDB引擎接口取这个表的第一行，判断tb_id 值是不是66，如果不是则跳过，如果是则将这行缓存在结果集中;
- 调用引擎接口取”下一行"，重复相同的判断逻辑，直到取到这个表的最后一行。
- 执行器将上述遍历过程中所有满足条件的行组成的结果集返回给客户端。
- 至此，这个语句就执行完成了。