mysql查询执行过程

查询优化，索引优化，库表结构优化需要齐头并进，一个不落。

首先要稍微了解一下查询执行的基础，当希望mysql高性能运行查询时，最好的办法就是弄清楚mysql是如何优化和执行查询的。一旦理解这一点，很多查询工作实际上就是遵循一些原则让优化器能够按照预想的合理方式运行。

当客户端发送了一个sql查询请求，那么mysql服务器首先去查找缓存，如果缓存命中，则跳过所有的步骤，直接返回结果。这个检查是对一个哈希查找，即时有一个字节的不同，也不会匹配缓存。

生命周期的下一步是将一个sql转化成一个执行计划，mysql再依照这个执行计划和存储引擎进行交互。
1，语法解析：将sql生成一颗对应的解析树，期间进行语法检查，一旦发现错误就终止查询。
2，预处理：检查表名，列名是否存在，别名是否有歧义等。
3，查询优化器：作用是将解析树转化为执行计划。一条sql可以有很多种执行方式，最后都返回相同的结果。优化器的作用是找到最好的执行计划。mysql使用基于成本的优化器，它将尝试预测一个查询使用某种计划时的成本，并选择其中最小的一个。最初，成本最小单位是随机读取一个4k数据页的成本，后来成本公式就变得很复杂。
可以用语句 show status like ‘last_query_cost’来查看上一次查询的查询成本。得到的值为查询数据页的个数（数据页的概念应该是跟操作系统有关系的，比如4kB数据为一个数据页，不同的操作系统可能会不一样）。值得注意的是，估算跟实际执行还是有不一致的时候，也就是说优化器选择的方案也可能不是最优的。比如有的执行计划虽然需要读取更多的页面，但是这些读取的成本却很小，比如这些数据是顺序存放的。
下面是mysql能够处理的优化类型：
3.1，重新定义关联表的顺序： 数据表的关联并不总是按照查询中指定的顺序进行。决定关联的顺序是优化器很重要的一部分功能。
3.2，将外连接转化为内连接
3.3，使用等价变换规则：例如将 5=5 and a<5优化为a<5
3.4，优化count,min,max：例如，如果此列有b-tree索引，那么在优化的时候，会直接取b-tree最左边的值（min），将其作为一个常数。在执行的时候，这一步就略了，因为优化的时候已经是一个常数了。对于myisam存储引擎，因为其维护了一个count值，所以在没有where的查询中，直接用这个值来替代count语句。
3.5，预估并转化为常数表达式：
3.6，检查是否能够使用覆盖索引
3.7，子查询优化：mysql在某些情况下可以将自查询转换为一种效率更高的形式，，从而减少多个查询多次对数据进行访问。
3.8，其他优化

数据和索引的统计信息：
在服务器层有查询优化器，却没有保存数据和索引的统计信息。统计信息由存储引擎实现，不同的存储引擎可能会存储不同的统计信息。mysql查询优化器在生成查询的执行计划时，需要向存储引擎获取统计信息。包括：每个表或者索引有多少个页面，索引的分布信息等。

mysql如何执行关联查询

先来看一个union查询的列子，mysql先将一系列的单个查询结果放到一个临时表中，然后重新读出临时表数据来完成union查询。在mysql的概念中，每个查询都是一次关联，读取结果临时表也算也此关联。
对于两个表关联的情况，也许有人会认为具体执行像编程语言中的双层for循环，事实其实也是这样。
mysql执行关联查询的的操作很固定，即mysql先在一个表中循环去除单挑数据，然后再嵌套循环到下一个表中寻找匹配的行，一次下去。

关联查询优化器：它决定了多个表关联时的顺序。通常多表关联的时候，可以有多种不同的关联顺序获得相同的执行结果。关联查询优化器通过评估不同的顺序的成本来选择一个代价最小的关联顺序。面试的时候总有人问表的连接顺序，其实这些东西最后都会被mysql服务器优化的。