侧边栏壁纸
  • 累计撰写 244 篇文章
  • 累计创建 16 个标签
  • 累计收到 0 条评论
隐藏侧边栏

MySQL 服务端整体架构和 SQL 查询语句的执行流程

kaixindeken
2021-04-26 / 0 评论 / 0 点赞 / 82 阅读 / 2,240 字

MySQL 数据库客户端成功建立与服务端的连接和并完成用户认证后,就可以发送 SQL 语句与服务端交互了:

1.jpeg

服务端整体架构

MySQL 服务端的整体架构:

1.jpeg

可以看到服务端主要由 Server 层和存储引擎两部分组成:

  • Server 层包括连接器、查询缓存、分析器、优化器、执行器等,涵盖 MySQL 的大多数核心服务功能,以及所有的内置函数,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图等。
  • 存储引擎层负责数据的存储和提取,其架构模式是插件式的,支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

查询缓存

当 MySQL 服务端拿到一条 SQL 查询语句后,首先会查询缓存,看之前是不是执行过这条语句。如果执行过,会缓存在内存中,这个时候直接返回之前缓存的查询结果给客户端即可;如果在缓存中没有找到对应的记录,就会继续后面的操作,并且在最终执行完成后,将查询结果保存到查询缓存。

可以看到,如果命中查询缓存,MySQL 不需要执行后面的复杂操作就可以直接返回结果,查询效率会很高。但是通常不建议这么做,原因和是否要在业务逻辑中保存模型类查询结果一样:因为这个缓存的 key 是查询语句,只要有一点不同(实际项目中查询字段、查询条件千姿百态)就会导致缓存命中失败,同时,数据表记录本身也是不断更新(插入、更新、删除)的,更新之后,之前的查询缓存就全部失效了,所以从维护成本和实际收益上看,得不偿失。除非这张表创建初始化后不怎么更新,是一个静态表,并且查询语句相对单一。

注:MySQL 8.0 版本开始将不再支持查询缓存功能。

你可以通过 show variables like '%query_cache%'; 语句查看系统查询缓存设置:

1.jpeg

query_cache_type 为 OFF 表示默认关闭。你可以在配置文件中配置该值来决定是否启用查询缓存。

分析器

如果查询缓存没有启用或者没有命中,就开始真正执行 SQL 查询语句了。

MySQL 会通过分析器对 SQL 语句做词法分析,以确定到底要做什么,比如 select 表示查询语句,update 表示更新语句等,表名是什么,查询的字段有哪些,查询的条件是什么。

确定要做的事情之后,分析器还会对 SQL 语句进行语法分析,以确保符合 MySQL 语法,你可能对 You have an error in your SQL syntax 这个报错很熟悉,这就是 SQL 语句语法错误的提示(重点关注「use near」后面的错误原因):

1.jpeg

优化器

如果 SQL 语句词法和语法分析都没有问题,接下来,会经由优化器生成执行计划,这里面主要的工作是数据表包含索引的时候,判定是否使用索引,以及使用哪些索引效率最高(扫描行数最少),我们可以在执行一个 SQL 查询语句之前通过 explain 语句查看它的执行计划:

1.jpeg

执行器

通过分析器可以知道客户端发送的 SQL 语句要做什么,通过优化器可以确定要怎么做,最后就是真正去执行了,这一步通过服务端的执行器完成。

在根据执行计划执行 SQL 查询语句时,会先验证权限,有相应的权限才会继续执行,否则会报权限错误。

在具体执行查询操作时,是通过调用存储引擎提供的 API 接口完成的,MySQL 支持不同的存储引擎,虽然这些存储引擎存取数据的底层实现不尽相同,但是对 Server 层提供了统一的接口,执行器调用这些接口可以完成诸如读取下一行记录、插入记录、更新记录之类的日常数据库操作,执行 SQL 查询返回所有满足条件的结果集也是如此。

在存储引擎中进行查询操作时,如果 SQL 语句没有使用索引,则需要一条条遍历数据表的所有记录(全表扫描),然后将满足条件的记录存放到结果集,直到数据表最后一行,最后再把这个结果集返回给客户端。如果数据表非常大,表记录非常多时,这种查询的效率会很低下,这是我们在优化数据库查询效率时所要极力避免的现象。

反之,如果 SQL 查询语句中使用了索引,则可以极大提升查询效率。

0

评论区