表连接sql执行计划学习
循环嵌套连接(Nested Loop Join)
合并连接(Merge Join)
哈西匹配（Hash Join）
循环嵌套，如果内循环列上有索引，将进行索引扫描；如果内循环列上没有索引，则可能进行全表扫描。
这种情况尽量让内部表有序，也就是有索引；并且外部循环表的行数要小于内部循环的行数。
否则查询分析器，倾向于进行Hash Join。
需要分析得出，随着数据量的增长，这种嵌套循环方式对性能的消耗，将呈现出指数级别的增长。
连接的索引无法覆盖所求查询，必须通过书签查找来进行，这也是为什么我们要养成只Select需要的列的好习惯，为了解决上面的问题，我们既可以用覆盖索引，也可以减少所需的列来避免书签查找。
不理解词
书签查找
强制表扫描
Merge Join其实上就是将两个有序队列进行连接，需要两端都已经有序，所以不必像Loop Join那样不断的查找循环内部的表。其次，Merge Join需要表连接条件中至少有一个等号查询分析器才会去选择Merge Join。
通常来说Merge Join如果输入两端有序，则Merge Join效率会非常高，但是如果需要使用显式Sort来保证有序实现Merge Join的话，那么Hash Join将会是效率更高的选择。但是也有一种例外，那就是查询中存在order by,group by,distinct等可能导致查询分析器不得不进行显式排序，那么对于查询分析器来说，反正都已经进行显式Sort了,何不一石二鸟的直接利用Sort后的结果进行成本更小的MERGE JOIN？在这种情况下，Merge Join将会是更好的选择。
另外，我们可以由Merge Join的原理看出，当连接条件为不等式(但不包括!=)，比如说> < >=等方式时，Merge Join有着更好的效率。
哈希匹配连接相对前面两种方式更加复杂一些，但是哈希匹配对于大量数据，并且无序的情况下性能均好于Merge Join和Loop Join。对于连接列没有排序的情况下(也就是没有索引)，查询分析器会倾向于使用Hash Join。
哈希匹配分为两个阶段,分别为生成和探测阶段，首先是生成阶段
通过了解哈希匹配的原理不难看出，哈希匹配涉及到散列函数，所以对CPU的消耗会非常高，此外，在Hash Bucket中的行是无序的，所以输出结果也是无序的。图13是一个典型的哈希匹配
下面我们通过一个表格简单总结这几种连接方式的消耗和使用场景:
| 嵌套循环连接 | 合并连接 | 哈希连接 | |
| 适用场景 | 外层循环小，内存循环条件列有序 | 输入两端都有序 | 数据量大，且没有索引 |
| CPU | 低 | 低（如果没有显式排序） | 高 |
| 内存 | 低 | 低（如果没有显式排序） | 高 |
| IO | 可能高可能低 | 低 | 可能高可能低 |
