执行流程

如下图所示，我们可以看到当向 MySQL 发送一个请求时，MySQL 到底做了什么：  

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

 

查询缓存

　　在解析一个查询语句之前，如果查询缓存时打开的，那么 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 在这个阶段也会将结果存放到查询缓存中。