接下来是探测阶段，对于另一个输入集合，同样针对每一行进行散列函数，确定其所应在的Hash Bucket,在针对这行和对应Hash Bucket中的每一行进行匹配，如果匹配则返回对应的行。
通过了解哈希匹配的原理不难看出，哈希匹配涉及到散列函数，所以对CPU的消耗会非常高，此外，在Hash Bucket中的行是无序的，所以输出结果也是无序的。图13是一个典型的哈希匹配，其中查询分析器使用了表数据量比较小的Product表作为生成，而使用数据量大的SalesOrderDetail表作为探测。
图13.一个典型的哈希匹配连接
上面的情况都是内存可以容纳下生成阶段所需的内存，如果内存吃紧，则还会涉及到Grace哈希匹配和递归哈希匹配，这就可能会用到TempDB从而吃掉大量的IO。这里就不细说了,有兴趣的同学可以移步:http://msdn.microsoft.com/zh-cn/library/aa178403(v=SQL.80).aspx。总结
下面我们通过一个表格简单总结这几种连接方式的消耗和使用场景:
| 嵌套循环连接 | 合并连接 | 哈希连接 | |
| 适用场景 | 外层循环小，内存循环条件列有序 | 输入两端都有序 | 数据量大，且没有索引 |
| CPU | 低 | 低（如果没有显式排序） | 高 |
| 内存 | 低 | 低（如果没有显式排序） | 高 |
| IO | 可能高可能低 | 低 | 可能高可能低 |
理解SQL Server这几种物理连接方式对于性能调优来说必不可少，很多时候当筛选条件多表连接多时，查询分析器就可能不是那么智能了，因此理解这几种连接方式对于定位问题变得尤为重要。此外，我们也可以通过从业务角度减少查询范围来减少低下性能连接的可能性。
参考文献:
http://msdn.microsoft.com/zh-cn/library/aa178403(v=SQL.80).aspx
http://www.dbsophic.com/SQL-Server-Articles/physical-join-operators-merge-operator.html
