哈希联接可以有效处理未排序的大型非索引输入。它们对复杂查询的中间结果很有用，因为：
· 中间结果未经索引（除非已经显式保存到磁盘上然后创建索引），而且通常不为查询计划中的下一个操作进行适当的排序。
· 查询优化器只估计中间结果的大小。由于对于复杂查询，估计可能有很大的误差，因此如果中间结果比预期的大得多，则处理中间结果的算法不仅必须有效而且必须适度弱化。
原理
Hash join一般用于一张小表和一张大表进行join时。Hash join的过程大致如下（下面所说的内存就指sort area，关于过程，后
面会作详细讨论）：
1． 一张小表被hash在内存中。因为数据量小，所以这张小表的大多数数据已经驻入在内存中，剩下的少量数据被放置在临时表空间中；
2． 每读取大表的一条记录，就和小表中内存中的数据进行比较，如果符合，则立即输出数据（也就是说没有读取临时表空间中的小表的数
据）。而如果大表的数据与小表中临时表空间的数据相符合，则不直接输出，而是也被存储临时表空间中。
3． 当大表的所有数据都读取完毕，将临时表空间中的数据以其输出。
如果小表的数据量足够小（小于hash area size），那所有数据就都在内存中了，可以避免对临时表空间的读写。
如果是并行环境下，前面中的第2步就变成如下了：
2．每读取一条大表的记录，和内存中小表的数据比较，如果符合先做join，而不直接输出，直到整张大表数据读取完毕。如果内存足够，
Join好的数据就保存在内存中。否则，就保存在临时表空间中。
1,处理大量、未排序、无索引的数据
2 ,Hash Join一个较大限制是它只能应用于等值联结(equality join)，这主要是由于哈希函数及其桶的确定性及无序性所导致的。
我们在这里看看blog中的例子：
原贴： http://www.cnblogs.com/perfectdesign/archive/2008/04/24/sql_tuning.html
USE TempDB
GO
CREATE TABLE b1 (blat1 nCHAR(5) NOT NULL)
CREATE TABLE b2 (blat2 VARCHAR(200) NOT NULL)
GO
INSERT b1
SELECT LEFT(AddressLine1, 5) AS blat1 FROM AdventureWorks.Person.Address
INSERT b2
SELECT AddressLine1 AS blat2
FROM AdventureWorks.Person.Address
GO
然后执行如下的查询语句：
SELECT * FROM b1
JOIN b2 ON b2.blat2 LIKE b1.blat1 + '%'
上面牛人blog提出的问题，不建立任何对象（索引，索引视图等），优化这个语句。其实这就是考察hash联结的使用。
分析语句：
1. 选择算法：
1，由于hash联结只能用相等联结才能使用，这时两个表b1,b2通过like来联结，结果肯定不会是hash联结
2，由于这里的联结是inner join 而这时使用merge联结同样需要两个字段关联查询，结果肯定不会是merge联结
3，由于3个联结2个不满足条件，这时优化器只能采用loop嵌套循环联结
2，如何执行loop联结
通过上面的分析，我们已经看到了只能采用loop嵌套循环。b1,b2都没有索引。
假如b1有1万条，b2有2万条。
看看执行结果：根据嵌套循环算法，是两个循环。由于都没有索引，系统先表扫描b1表1万，在通过逐条表扫描b2两万条。
最少IO总数: 1万（b1的行数）*表b2的扫描IO次数+b1表扫描IO次数。
测试上面IO次数计算例子：
表 [zping.com]中有1000条记录，id为唯一32id，通过id插入数据到b1,b2中。两个表各写入1000行，返回io数：
(1002 行受影响)
表 'Worktable'。扫描计数 2，逻辑读取 12068 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'b2'。扫描计数 2，逻辑读取 16 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'b1'。扫描计数 3，逻辑读取 4 次，物理读取 0 次，预读 24 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
按照上面的公式：4+1002*8=8020次IO 和这里IO次数比较比较起来，差距较大。
可以看出，IO数要比上面的公式大。
如果要优化就不能使用嵌套循环算法 。一些网友也给出了解决办法：最优的方法是：
from (select blat1 s from b1) a
join (select left(blat2,5) s from b2) b
on a.s=b.s
如果换成了
from (select distinct blat1 s from b1) a
join (select distinct left(blat2,5) s from b2) b
on a.s=b.s
对比成本，发现hash联结要比merge联结要快，因为这里有一个distinct显示排序操作，数据库会自动采取合并算法。
因为有了排序操作，成本就比hash慢。
因此最佳优化的SQL语句：
from (select blat1 s from b1) a
join (select left(blat2,5) s from b2) b
on a.s=b.s
如何使用Hash联结。
今天又看了一下阿里巴巴的dba，在Oracle里的研究hash联结的优化和例子：
http://www.alidba.net/index.php/archives/83
他得出的结论:
1. hash的时候一定要用小记录集做驱动.
2. 大/小记录集作驱动时, 读取数据文件的cost两者是一样的.但是前者的记录集在大到一定程度的时候, 在构建hash桶会产生很多物理读, 而且这些物理读根本无法消除, 每次执行都会产生.
我们测试一下，看看不同的驱动表对hash联结的性能影响：
表workflowinfo1 有50多万条记录，表workflowlog1有70多万数据。
执行一下语句：
inner hash join dbo.workflowlog1 b on a.workflowid=b.workflowid
select * from dbo.workflowlog1 a
inner hash join dbo.workflowinfo1 b on a.workflowid=b.workflowid
一个是以workflowinfo1为驱动表，一个是以workflowlog1为驱动表。对比成本：
这时发现以小的驱动表（workflowinfo1,50多万）成本较少。而多的驱动表（workflowlog1,70多万）成本较高。
这里我们得出结论：
1，hash联结适合输入和输出都是大型数据集的情况。
2，联结列必须相等联结，（不相等可以如上方法换成相等联结）
3，使用较少的表为驱动表。（在使用hash提示联结尤其注意）