表连接sql执行计划学习

循环嵌套连接(Nested Loop Join)

合并连接(Merge Join)

哈西匹配（Hash Join）

文章：浅谈SQL Server中的三种物理连接操作

循环嵌套，如果内循环列上有索引，将进行索引扫描；如果内循环列上没有索引，则可能进行全表扫描。

这种情况尽量让内部表有序，也就是有索引；并且外部循环表的行数要小于内部循环的行数。

否则查询分析器，倾向于进行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	可能高可能低	低	可能高可能低