MySQL执行一条查询语句的过程
执行流程
如下图所示,我们可以看到当向 MySQL 发送一个请求时,MySQL 到底做了什么:
![](https://img2020.cnblogs.com/blog/1214003/202109/1214003-20210911101154503-1896503875.png)
- 客户端发送一条査询给服务器。
- 服务器先检查査询缓存,如果命中了缓存,则立刻返回存储在缓存中的结果。否则进入下一阶段。
- 服务器端进行 SQL 解析、预处理,再由优化器生成对应的执行计划。
- MySQL 根据优化器生成的执行计划,调用存储引擎的 API 来执行查询。
- 将结果返回给客户端。
查询缓存
在解析一个查询语句之前,如果查询缓存时打开的,那么 MySQL 会优先检查这个查询是否命中查询缓存中的数据。这个检查时通过一个对大小写敏感的哈希查找实现的。查询和缓存中的查询即使只有一个字节不同,那也不会匹配缓存结果。
如果当前的查询恰好命中了缓存,那么在返回结果之前 MySQL 会检查一次用户权限。这仍然是无须解析查询 SQL 语句的,因为在查询缓存中已经存放了当前查询需要访问的表信息。如果权限没有问题,MySQL 会跳过所有其他阶段,直接从缓存中拿到结果并返回给客户端。跳过了解析、优化和执行阶段。
查询缓存系统会跟踪查询表中涉及的每个表,如果这些表发生变化,那么和这个表相关的所有缓存数据都将失效。这种机制效率看起来比较低,因为数据变化时很有可能对应的查询结果并没有变更,但是这种简单实现代价很小,而这点对于一个非常繁忙的系统来说非常重要。
有关查询缓存的配置
query_cache_type
是否打开查询缓存。可以设置成 OFF、ON 或者 DEMAND。DEMAND 表示只有在查询语句中明确写明 SQL_CACHE 的语句才放入查询缓存。
query_cache_size
查询缓存使用的总内存空间,单位是字节。这个值必须是 1024 的整数倍,否则 MySQL实际分配的数据会和你指定的略有不同。
query_cache_min_res_unit
在查询缓存中分配内存块时的最小单位。
query_cache_limit
MySQL 能够缓存的最大查询结果。如果查询结果大于这个值,则不会被缓存。
query_cache_wlock_invalidate
如果某个数据表被其他的连接锁住,是否仍然从拆线呢缓存中返回结果。这个参数默认是 OFF,这可能在一定程度上会改变服务器的行为,因为这使得数据库可能返回其他线程锁住的数据。将参数设置为 ON,则不会从缓存中读取这类数据,但是这可能会增加锁等待。对于绝大多数应用来说无需注意这个细节,所以默认设置通常是没有问题的。
语法解析器和预处理
首先,MySQL 通过关键字将 SQL 语句进行解析,并生成一颗对应的“解析树”。MySQL 解析器将使用 MySQL 语法规则验证和解析查询。例如,它将验证是否使用错误的关键字,或者使用关键字的顺序是否正确等,再或者它还会验证引号是否能前后正确匹配。
预处理器则根据一些 MySQL 规则进一步检查解析树是否合法,例如,这里将检查数据表和数据列是否存在,还会解析名字和别名,看看它们是否有歧义。
下一步预处理器会验证权限。这通常很快,除非服务器上有非常多的权限配置。
查询优化器
现在语法树被认为是合法的了,并且由优化器将其转化成执行计划。一条查询可以有很多种执行方式,最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。
MySQL 使用基于成本的优化器,它将尝试预测一个查询使用某种执行计划时的成本,并选择其中成本最小的一个。
MySQL 查询优化器在生成查询的执行计划时,需要向存储引擎获取相应的统计信息。存储引擎则提供给优化器对应的统计信息,包括:每个表或索引有多少个页面、每个表的每个索引的基数是多少、数据行和索引长度、索引的分布信息等。优化器根据这些信息来选择一个最优的执行计划。
查询执行引擎
相对于查询优化阶段,查询执行阶段不是那么复杂:MySQL 只是简单地根据执行计划给出地指令逐步执行。在根据计划逐步执行的过程中,有大量的操作需要通过调用存储引擎实现的接口来完成。
返回结果给客户端
查询执行的最后一个阶段是将结果返回给客户端。即使查询不需要返回结果集给客户端,MySQL 仍然会返回这个查询的一些信息,如该查询影响到的行数。
如果查询可以被缓存,那么 MySQL 在这个阶段也会将结果存放到查询缓存中。