查询的生命周期的下一步是将一个SQL转换成一个可执行计划，MySQL再按照这个计划和存储引擎进行交互
语法解析器和预处理首先，MySQL通过关键词将SQL语句进行解析，并生成一颗对应的“解析树”。MySQL解析器将使用MySQL语法规则验证和解析查询。比如是否使用了错误的关键字，关键字的顺序是否正确，或者引号是否能够正确的前后匹配。
预处理器则会根据一些MySQL规则进一步检查解析树是否合法。它会检查数据表和数据列是否存在，还会解析名字和别名，看看它们是否存在歧义。
查询优化器当语法树被认为是合法的时候，将转由优化器去转化成执行计划。一条查询可以有很多种执行方式，最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。
MySQL使用的是基于成本的优化器，它将会尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的那一个。可以通过查询当前会话的“Last_query_cost”的值来的值MySQL计算的当前查询的成本。
这个结果表示MySQL的优化器认为大概需要做1040个数据页的随机查找才能够完成上面的查询。这是根据一系列的统计信息计算的来的。优化器在评估成本时并不会考虑任何层面的缓存，它假设读取任何数据都需要一次磁盘I/O。
有很多种情况会导致MySQL优化器选择错误的执行计划，如下所示：
统计信息不准确。 MySQL依赖存储引擎提供的统计信息来评估成本，但是有的存储引擎提供的信息偏差非常大。比如InnoDB因为使用了MVCC架构，并不能维护一个数据表的行数的精确统计信息。
执行计划中的成本估算不等同于实际执行的成本。 所以及时统计信息精准，优化器给出的执行计划也可能不是最优的。比如某个执行计划虽然需要读取很多的页面，但是如果这些页面都是顺序读取获取已经在内存中了的话，那么访问它的成本将非常小。
MySQL的最优可能和我们想的最优是不同的。 我们理解的最优是执行时间尽可能短，但是MySQL只是基于其成本模型选择最优的执行计划，而有些时候并不是最快的执行方式。
MySQL从不考虑其他正在并发执行的查询，这可能会影响当前查询的速度。
MySQL并不是任何时候都基于成本的优化。 有时候它也会基于一些固定的规则，比如存在全文搜索的MATCH()子句时，MySQL会选择使用全文索引而不是使用其他更快的索引或者WHERE条件。
MySQL不会考虑不受其控制的操作的成本，比如执行存储过程或者用户自定义函数的成本。
优化器有时候无法去估算所有可能的执行计划，所以可能会错过实际上最优的执行计划。
MySQL的查询优化器是一个非常复杂的不见，它使用了很多优化策略来生成一个最优的执行计划。优化策略可以简单的分为两种，一种是静态优化，一种是动态优化。
静态优化可以直接对解析树进行分析，并完成优化。例如通过一些简单的袋鼠变换将WHERE条件转换成另一种等价形式，可以认为是一种“编译时优化”。
动态优化则是和查询的上下文相关，也可能和很多其他因素有关，这些需要在每次查询时重新评估，可以认为是“运行时优化”
。
在执行语句和存储过程的时候，动态优化和静态优化的区别很重要。MySQL对查询的静态优化只需要做一次，但是对查询的动态优化则在每次执行时都需要重新评估。有时候甚至在查询的执行过程中也会重新优化。
下面是一些MySQL可以处理的优化类型：
重新定义关联表的顺序
将外连接转化为内连接
使用等价变换规则。 它可以合并和减少一些比较，还可以移除一些恒成立和一些恒不成立的判断。
优化COUNT()、MIN()和MAX()。 索引和列是否为空通常可以帮助MySQL优化这类表达式。比如需要找到某一列的最小值，只需要查询对应B-Tree索引的最左端记录即可。
预估并转化为常量表达式。 当MySQL检测到一个表达式可以转化为常数时，就会一直把该表达式作为常数进行优化处理。
覆盖索引扫描。 当索引中的列包含所有查询中需要使用的列的时候，MySQL就可以使用索引返回需要的数据，而无需查询对应的数据行。
子查询优化
提前终止查询。 当发现已经满足查询需求的时候，MySQL总是能够立刻终止查询。一个典型的例子就是当使用了LIMIT 子句的时候。
等值传播。 如果两个列的值通过等式关联，那么MySQL能够把其中一个列的WHERE条件传递到另一列上。