这里继续上一篇中的优化器部分：mysql如何执行关联查询mysql对任何关联都执行嵌套循环关联操作，即先在一个表中循环取出单条数据，然后再嵌套循环到下一个表中寻
这里继续上一篇中的优化器部分：
mysql如何执行关联查询
mysql对任何关联都执行嵌套循环关联操作，即先在一个表中循环取出单条数据，然后再嵌套循环到下一个表中寻找匹配的行，依次下去，直到找到所有表中匹配的行为止。然后根据各个表匹配的行，返回查询中需要的各个列。mysql会尝试在最后一个关联表中找到所有匹配的行，，如果最后一个关联表无法找到更多的行以后，mysql返回到上一层次关联表，看是否能够找到更多的匹配记录，依次类推迭代执行。
例如：
select tab1.col1,tab2.col2from tab1 inner join tab2 using(col3)where tab1.col1 in (5,6);
执行计划
mysql执行查询的方式总是从一个表开始一直嵌套循环，回溯完成的所有表的关联。所以mysql执行计划总是一颗左侧深度优先的树。
mysql优化器最重要的一部分就是关联查询优化，它决定多个表关联时的顺序。通常多表关联的时候，可以有多种不同的关联顺序来获得相同的执行结果。关联查询优化器则通过评估不同顺序时的成本来选择一个代价最小的关联顺序。
如果超过n个表的关联，优化器选择使用贪婪搜索的方式查找最优的关联顺序，实际上当需要关联的表超过optimizer_search_depth的限制时，就会选择贪婪模式。
排序优化
当不能使用索引生成排序的时候，就会使用文件排序，数据量小则在内存中，如果数据量大则需要使用磁盘。
但是mysql在进行文件排序的时候需要使用的临时空间可能会比想象的要大很多。原因在于mysql在排序时，对每一个排序记录都会分配一个足够长的定长空间来存放。
在关联查询需要排序时，会有两种情况来处理文件排序。如果order by子句中所有的列都来自关联的第一个表，那么mysql在关联处理第一个表的时候就进行文件排序，这个时候在explain的extra中就会有using filesort。除此之外的所有情况，mysql都会先将关联的结果存放到一个临时表中，然后在所有关联都结束后，再进行文件排序。这总情况下explain的extra中可以看到using temporary;using filesort。即使有limit，也会在排序之后应用。不过这个情况在5.6之后可能会有所改进了。
4、查询执行引擎
存储引擎的接口有着非常丰富的功能，但是底层接口却只有几十个，这种简单的接口模式让mysql的存储引擎插件架构成为可能。
5、返回结果给客户端
如果查询可以被缓存，那么mysql在这个阶段也会将结果存放到查询缓存中去。
mysql将结果集返回客户端是一个增量、逐步返回的过程。这样有2个好处：
a、服务器端无须存放太多的结果，也就不会因为要返回太多的结果而消耗太多的内存。
b、客户端第一时间就可以获得返回的结果。
至此，查询执行机制的一些原理就完成了！！
本文出自 “phper-每天一点点~” 博客，请务必保留此出处