一文读懂一条 SQL 查询语句是如何执行的( 四 )

mysql> select SQL_CACHE * from t1 where id = 1; 如果没有命中或者没有开启查询缓存， MySQL 服务器接下来要做的就是将一条 SQL 语句转换成一个执行计划，再依照这个执行计划和存储引擎进行交互。这包括多个子阶段：解析 SQL、预处理、优化 SQL 执行计划。这个过程中任何错误（例如语法错误）都可能终止查询。
其中解析 SQL 和预处理就是解析器做的事情，优化 SQL 执行计划就是优化器做的事情。这里我们先说解析器。
这里《高性能 MySQL - 第 3 版》书中分得更细致点，解析器用来解析 SQL ，预处理器则用来预处理，我暂且把它们都归为解析器吧
所谓解析 SQL 就是说， MySQL 通过关键字对 SQL 语句进行解析，并生成一棵对应的 “解析树” ，用于根据语法规则来验证语句是否正确。例如，它将验证是否使用错误的关键字，或者使用关键字的顺序是否正确等，再或者它还会验证引号是否能前后正确匹配。
而预处理则会进一步检查解析树是否合法，例如，检查数据表和数据列是否存在，检查表名和字段名是否正确等。
现在，解析树是合法的了， MySQL 已经知道你要做什么了。不过，一条查询可以有很多种执行计划，最后都返回相同的结果，那到底该选择哪种执行计划呢？
举个简单的例子：
mysql> select * from t1 where id = 10 and name = "good"; 对于上面这个语句，可以先查找 name = good 再查找 id = 10 ，也可以先查找 id = 10 再查找 name = good ，这两种不同的执行计划可能耗费的时间成本是不一样的。
那么优化器的作用就是找到这其中最好的执行计划。需要注意的是，这里的执行计划是一个数据结构，而不是和很多其他的关系型数据库那样会生成对应的字节码。
另外，优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。
当优化器阶段完成后，这个语句的执行计划就确定下来了，就可以进入执行器阶段了。
和命中查询缓存一样，在开始执行 SQL 语句之前，执行器会先判断一下当前用户对这个表有没有执行查询的权限，如果没有，就会返回没有权限的错误。
权限认证完成后， MySQL 就会根据执行计划给出的指令逐步执行。在根据执行计划逐步执行的过程中，有大量的操作需要通过调用存储引擎实现的接口来完成，这些接口也就是我们称为 “handler API” 的接口。
查询中的每一个表由一个 handler 的实例表示。实际上， MySQL 在优化阶段就为每个表创建了一个 handler 实例，优化器根据这些实例的接口可以获取表的相关信息，包括表的所有列名、索引统计信息，等等。