mysql体系结构和sql查询执行过程简析

一: mysql体系结构

1）Connectors
不同语言与 SQL 的交互

2）Management Serveices & Utilities 系统管理和控制工具
备份和恢复的安全性，复制，集群，管理，配置，迁移和元数据

3）Connection Pool 连接池
进行身份验证、线程重用，连接限制，检查内存，数据缓存；管理用户的连接，线程处理等需要缓存的需求

4）SQL Interface SQL 接口
进行 DML、DDL，存储过程、视图、触发器等操作和管理；用户通过 SQL 命令来查询所需结果

5）Parser 解析器
查询翻译对象的特权；SQL 命令传递到解析器的时候会被解析器验证和解析

6）Optimizer 查询优化器
在 MySQL 优化语句过程中，可以通过设置 optimize_switch 控制优化行为。在生产环境上，某时间段 MySQL 服务器压力特别大，load 一度达到了 100，查询发现数据库中有大量的 sql 语句 state 状态 result sorting ，result sorting 这种排序特别消耗 cpu 和内存资源。抽取其中的一条 sql 查看执行计划

7）Cache 和 Buffer：查询缓存
全局和引擎特定的缓存和缓冲区

8）Engine 存储引擎
各种存储引擎 InnoDB, MyISAM等等

上面的虽然给出来整体的结构体系，但是看起来感觉比较蒙

简化版本mysql逻辑结构

如果能在脑海中构建一幅MySQL各个组件之间协同工作的架构图，那么有助于你理解MySQL服务器

1）第一层：客户端
MySQL逻辑架构整体分为三层，最上层为客户端层，并非MySQL所独有，诸如：连接处理、授权认证、安全等功能均在这一层处理

2）第二层：核心服务（大方框内的）
MySQL大多数核心服务均在中间这一层，包括查询解析、分析、优化、缓存、内置函数(比如：时间、数学、加密等函数)。所有的跨存储引擎的功能也在这一层实现：存储过程、触发器、视图等

3）第三层：存储引擎
最下层为存储引擎，其负责MySQL中的数据存储和提取。和Linux下的文件系统类似，每种存储引擎都有其优势和劣势。中间的服务层通过API与存储引擎通信，这些API接口屏蔽了不同存储引擎间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含了几十个底层函数
存储引擎MyISAM, innodb等等

二：sql查询执行过程

弄清楚一条sql语句从开始到执行结束，中间到底要经过哪些步骤，哪些过程，了解之后。我们也可以对各个步骤逐一优化。
向mysql发送一个请求，MySQL到底做了什么？
查询的生命周期大致按照顺序来看：从客户端，到服务器，然后在服务器上进行解析，生成执行计划，执行，并返回结果给客户端。 其中“执行” 可以认为是整个生命周期最重要的阶段，这其中包括大量了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序，分组等等。
看图：

上图执行步骤：

1. 客户端向MySQL服务器发送一条查询请求
2. 服务器首先检查查询缓存，如果命中缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段
3. 服务器进行SQL解析、预处理、
4. 再由优化器生成对应的执行计划
5. MySQL根据执行计划，调用存储引擎的API来执行查询
6. 将结果返回给客户端，同时缓存查询结果

1）MySQL客户端/服务端通信协议
一般来说，不需要去了解MySQL通信协议的内部实现细节，只需要大致了解通信协议是如何工作就好了。
MySQL客户端/服务端通信协议是“半双工”的：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时发生。一旦一端开始发送消息，另一端要接收完整个消息才能响应它，所以我们无法也无须将一个消息切成小块独立发送，也没有办法进行流量控制。

客户端用一个单独的数据包将查询请求发送给服务器，所以当查询语句很长的时候，需要设置max_allowed_packet参数。但是需要注意的是，如果查询实在是太大，服务端会拒绝接收更多数据并抛出异常。

与之相反的是，服务器响应给用户的数据通常会很多，由多个数据包组成。但是当服务器响应客户端请求时，客户端必须完整的接收整个返回结果，而不能简单的只取前面几条结果，然后让服务器停止发送。因而在实际开发中，尽量保持查询简单且只返回必需的数据，减小通信间数据包的大小和数量是一个非常好的习惯，这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一

2）查询缓存
在解析一个查询语句前，如果查询缓存是打开的，那么MySQL会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存，在检查一次用户权限后直接返回缓存中的结果。这种情况下，查询不会被解析，也不会生成执行计划，更不会执行。

3）语法解析和预处理
MySQL通过关键字将SQL语句进行解析，并生成一颗对应的解析树。这个过程解析器主要通过语法规则来验证和解析。比如SQL中是否使用了错误的关键字或者关键字的顺序是否正确等等。预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等

4）查询优化
经过前面的步骤生成的语法树被认为是合法的了，并且由查询优化器将其转化成执行计划。多数情况下，一条查询可以有很多种执行方式，最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。
MySQL使用基于成本的优化器，它尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。在MySQL可以通过查询当前会话的last_query_cost的值来得到其计算当前查询的成本

5）查询执行引擎
在完成解析和优化阶段以后，MySQL会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成，这些接口被称为handler API。查询过程中的每一张表由一个handler实例表示。实际上，MySQL在查询优化阶段就为每一张表创建了一个handler实例，优化器可以根据这些实例的接口来获取表的相关信息，包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能，但其底层仅有几十个接口，这些接口像搭积木一样完成了一次查询的大部分操作

6）返回结果给客户端
查询执行的最后一个阶段就是将结果返回给客户端。即使查询不到数据，MySQL仍然会返回这个查询的相关信息，比如该查询影响到的行数以及执行时间等等。
如果查询缓存被打开且这个查询可以被缓存，MySQL也会将结果存放到缓存中。
结果集返回客户端是一个增量且逐步返回的过程。有可能MySQL在生成第一条结果时，就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存，也可以让客户端第一时间获得返回结果。需要注意的是，结果集中的每一行都会以一个满足①中所描述的通信协议的数据包发送，再通过TCP协议进行传输，在传输过程中，可能对MySQL的数据包进行缓存然后批量发送。

参考资料：
《高性能MySQL》