Mysql 一条sql查询语句是如何执行的

MySQL 可以分为 Server 层和存储引擎层两部分

第一步：应用程序把查询SQL语句发送给服务器端执行
我们在数据库层执行SQL语句时，应用程序会连接到相应的数据库服务器，把SQL语句发送给服务器处理。

我们在数据库层执行SQL语句时，应用程序会连接到相应的数据库服务器，把SQL语句发送给服务器处理。

说明有个就表示现在系统里面有一个空闲连接

数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个

第二步：查询缓存
服务器在解析一个查询语句之前，如果查询缓存是打开的（MySQL默认打开，可以使用have_query_cache查看），在接收到查询请求后，并不会直接去数据库查询，而是在数据库的查询缓存中找是否有相对应的查询数据（某条给定的查询语句在第一次执行时，服务器会缓存这条查询语句和他返回的结果。）， 如果存在，那么在返回查询结果之前 MySQL会检查一次用户权限。 这仍然无需解析查询SQL语句， 因为查询缓存中已经存放了当前查询需要访问的表信息。 如果权限没有问题，key 是查询的语句，value 是查询的结果。 如果你的查询能够直接在这个缓存中找到 key， 那么这个 value 就会被则直接从缓存中拿到结果返回给客户端。 这种情况下， 查询不会被解析 ，不用生成执行计划，不会被执行。 而其中 是否命中缓存

是将此 查询语句和缓存中的查询语 句进行比对， 如果完全相同，那就认为它们是相同的，就认为命中缓存了。如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中

第三步：查询优化处理，生成执行计划 没有命中缓存
接下来服务器会将一个SQL转换成一个执行计划，而这个阶段包括： 解析SQL、预处理、优化SQL执行计划 ，其中任何一个阶段出错都会导致查询进行不下去。

解析SQL ：Mysql通过将SQL语句进行解析，并生成一棵对应的解析树。MySQL解析器将使用MySQL语法分析(语法规则验证)和解析查询，如将验证是否使用错误的关键字，或者关键字的顺序是否正确。

预处理 ：预处理器根据一些Mysql规则进一步检查解析树是否合法，如** 数据表 和数据列是否存在， 解析列名 和 别名 ，是否有歧义。接下来预处理器会验证用户权限(precheck)**。查看用户是否有相应的操作权限。

优化SQL ：优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有*多表关联（join）*的时候，决定各个表的连接顺序，将SQL语句转化成执行计划，一条查询可以有很多种执行方式，最后都返回相同的结果，最后找到其中最好的执行计划（Mysql使用基于成本的优化器，它将尝试预测一个查询使用某种执行计划的成本，选择其中成本最小的一个）。

例如 ** : mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20;

既可以先从表 t1 里面取出 c=10 的记录的 ID 值，再根据 ID 值关联到表 t2，再判断 t2 里面 d 的值是否等于 20。

也可以先从表 t2 里面取出 d=20 的记录的 ID 值，再根据 ID 值关联到 t1，再判断 t1 里面 c 的值是否等于 10。

这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。

第四步：Mysql根据相应的执行计划完成整个查询（此处的执行计划是一个数据结构）

Mysql根据执行计划给出的指令逐步执行 。在此过程中，有大量的操作需要通过调用存储引擎实现的接口完成，这些接口即为“handler API”接口。查询中的每一个表由一个handler的实例表示。（实际上，在优化阶段Mysql就为每一个表创建了一个handelr实例，优化器可以根据这些实例的接口获取表的相关信息，如表的所有列名、索引统计信息等）

存储引擎接口完成例如：

mysql> select * from T where ID=10;
　　　　　　　　ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

比如我们这个例子中的表 T 中，ID 字段没有索引，那么执行器的执行流程是这样的：

1、调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在结果集中；
2、调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
3、执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
4、至此，这个语句就执行完成了。

对于有索引的表 ，执行的逻辑也差不多。第一次调用的是“取满足条件的第一行”这个接口，之后循环取“满足条件的下一行”这个接口，这些接口都是引擎中已经定义好的

***数据库的慢查询日志中看到一个 rows_examined 的字段 ，***表示这个语句执行程序中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的

第五步：将查询结果返回客户端

如果查询可以缓存，Mysql在这个阶段也会将结果放到查询缓存中。
　　

Mysql 查询 缓存QUERY_CACHE

SHOW VARIABLES LIKE '%query_cache%';
SHOW STATUS LIKE 'Qcache%';
SHOW VARIABLES LIKE '%query_cache%';

主要看query_cache_size和query_cache_type的值是否跟我们设的一致：

这里query_cache_size的值是134217728，我们设置的是128M，实际是一样的，只是单位不同，可以自己换算下：134217728 = 12810241024。

query_cache_type设置为1，显示为ON，这个前面已经说过了。

query_cache_type 参数用于控制缓存的类型，注意这个值不能随便设置，必须设置为数字，可选项目以及说明如下：

如果设置为0 ，那么可以说，你的缓存根本就没有用，相当于禁用了。但是这种情况下query_cache_size设置的大小系统是否要为其分配呢，这个问题有待于测试？

如果设置为1 ，将会缓存所有的结果，除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。

SHOW STATUS LIKE 'Qcache%';

Qcache_free_blocks:表示查询缓存中目前还有多少剩余的blocks，如果该值显示较大，则说明查询缓存中的内存碎片过多了，可能在一定的时间进行整理。

**Qcache_free_memory:**查询缓存的内存大小，通过这个参数可以很清晰的知道当前系统的查询内存是否够用，是多了，还是不够用，DBA可以根据实际情况做出调整。

**Qcache_hits:**表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大，缓存效果越理想。

Qcache_inserts: 表示多少次未命中然后插入，意思是新来的SQL请求在缓存中未找到，不得不执行查询处理，执行查询处理后把结果insert到查询缓存中。这样的情况的次数，次数越多，表示查询缓存应用到的比较少，效果也就不理想。当然系统刚启动后，查询缓存是空的，这很正常。

**Qcache_lowmem_prunes:**该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值，用户可以适当的调整缓存大小。

Qcache_not_cached: 表示因为query_cache_type的设置,而没有被缓存的查询数量。

**Qcache_queries_in_cache:**当前缓存中缓存的查询数量。

**Qcache_total_blocks:**当前缓存的block数量。

Query Cache 命中率= Qcache_hits/(Qcache_hits+Qcache_inserts);

什么情况下查询缓存能发挥作用

并不是所有情况下查询缓存都能提高系统性能。打开查询缓存对读和写操作都会带来额外消耗：

·读查询在开始之前必须先检查是否命中缓存。

· 如果这个读查询可以被缓存，那么当完成执行后，需要将结果存入缓存。

· 每次写入操作时，需要将对应表的所有缓存都设置失效。如果缓存较大或碎片很多，则会带来很大消耗。

缓存命中率：

SHOW STATUS中能提供一个全局的性能指标用以计算缓存命中率：

每次SELECT查询，要么增加Qcache_hits（查询缓存命中次数），要么增加Com_select（无缓存的查询次数+错误查询+权限检查查询），所以命中率计算公式：Qcache_hits / (Qcache_hits + Com_select)。

如何判断一条sql语句是否命中了Query Cache

可以在运行这条SQL语句前后，分别运行如下语句，查看 Qcache_hits的值是否有增加，每次命中这个值会加1。如果没有命中Qcache_inserts的数量加1。

mysql>  show status like ‘Qcache%’ ;

两次执行期间Qcache_hits数没有变化， Qcache_inserts的值增加了1，说明这条SQL没有命中Query Cach

寄语：