MySQL语句执行流程

SQL语句执行流程
连接器（验证⽤户身份，给予权限）

查询缓存（存在缓存则直接返回，不存在则执⾏后续操作） MySQL将缓存存放在⼀个引⽤表（不要理解成table，可认为是类似于HashMap的数据结构），通过⼀个哈希值索引，这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等⼀些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同（例如：空格、注释），都会导致缓存不会命中。如果查询中包含任何⽤户⾃定义函数、存储函数、⽤户变量、临时表、MySQL库中的系统表，其查询结果都不会被缓存。⽐如函数NOW()或者CURRENT_DATE()会因为不同的查询时间，返回不同的查询结果，再⽐如包含
CURRENT_USER或者CONNECION_ID()的查询语句会因为不同的⽤户⽽返回不同的结果，将这样的查询结果缓存起来没有任何的意义。
既然是缓存，就会失效，那查询缓存何时失效呢？
MySQL的查询缓存系统会跟踪查询中涉及的每个表，如果这些表（数据或结构）发⽣变化，那么和这张表相关的所有缓存数据都将失效。正因为如此，在任何的写操作时，MySQL必须将对应表的所有缓存都设置为失效。如果查询缓存⾮常⼤或者碎⽚很多，这个操作就可能带来很⼤的系统消耗，甚⾄导致系统僵死⼀会⼉。⽽且查询缓存对系统的额外消耗也不仅仅在写操作，读操作也不例外：任何的查询语句在开始之前都必须经过检查，即使这条SQL语句永远不会命中缓存,如果查询结果可以被缓存，那么执⾏完成后，会将结果存⼊缓存，也会带来额外的系统消耗。

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

优化器（主要对执⾏的sql优化选择最优的执⾏⽅案⽅法） 经过前⾯的步骤⽣成的语法树被认为是合法的了，并且由优化器将其转化成查询计划。多数情况下，⼀条查询可以有很多种执⾏⽅式，最后都返回相应的结果。优化器的作⽤就是找到这其中最好的执⾏计划。MySQL使⽤基于成本的优化器，它尝试预测⼀个查询使⽤某种执⾏计划时的成本，并选择其中成本最⼩的⼀个。在MySQL可以通过查询当前会话的last_query_cost的值来得到其计算当前查询的成本(show status like ‘last_query_cost’😉。cost的数值代表优化器认为⼤概需要做多少个个数据⻚的随机查找才能完成上⾯的查询。这个结果是根据⼀些列的统计信息计算得来的，这些统计信息包括：每张表或者索引的⻚⾯个数、索引的基数、索引和数据⾏的⻓度、索引的分布情况等等。MySQL认为的最优跟我们想的不⼀样（我们希望执⾏时间尽可能短，但MySQL值选择它认为成本⼩的，但成本⼩并不意味着执⾏时间短）等等。

查询执行引擎，（执⾏时会先看⽤户是否有执⾏权限，有才去使⽤这个引擎提供的接⼝） 在完成解析和优化阶段以后，MySQL会⽣成对应的执⾏计划，查询执⾏引擎根据执⾏计划给出的指令逐步执⾏得出结果。整个执⾏过程的⼤部分操作均是通过调⽤存储引擎实现的接⼝来完成，这些接⼝被称为handler API。查询过程中的每⼀张表由⼀个handler实例表示。实际上，MySQL在查询优化阶段就为每⼀张表创建了⼀个handler实例，优化器可以根据这些实例的接⼝来获取表的相关信息，包括表的所有列名、索引统计信息等。存储引擎接⼝提供了⾮常丰富的功能，但其底层仅有⼏⼗个接⼝，这些接⼝像搭积⽊⼀样完成了⼀次查询的⼤部分操作。

去引擎层获取数据返回（如果开启查询缓存则会缓存查询结果）查询执⾏的最后⼀个阶段就是将结果返回给客户端。即使查询不到数据，MySQL仍然会返回这个查询的相关信息，⽐如该查询影响到的⾏数以及执⾏时间等。如果查询缓存被打开且这个查询可以被缓存，MySQL也会将结果存放到缓存中。结果集返回客户端是⼀个增量且逐步返回的过程。有可能MySQL在⽣成第⼀条结果时，就开始向客户端逐步返回结果集了。这样服务端就⽆须存储太多结果⽽消耗过多内存，也可以让客户端第⼀时间获得返回结果。