http://blog.sina.com.cn/s/blog_475e7d8901011byi.html
在做表join的时候， Oracle有三种方式， 与其说有三种方式， 不如说是三种策略。
分别是：
sort merge join(SMJ)
nest loop(NL)
hash join(HJ)
根据我的理解来讲讲这三种策略。
首先讲讲Row Source, 根据Oracle官方的解释，
Row source is a row set returned by a step in the execution plan along with a control structure that can iteratively process the rows. The row source can be a table, a view or result of a join or grouping operation.
总之， Row source是oracle根据执行计划生成的可操作数据集, 这种说法比Table更为严谨，因为join的两侧可能是view或者其他的object.
- sort merge join.
例如:
select * from t1 inner join t2 on t1.id=t2.id
首先会把row source1(t1)先载入内存， 进行排序， 然后把row source2(t2)载入内存，进行排序，然后进行merge操作。
什么是merge 操作？就是将两边的行按照连接条件连起来， (t1.id=t2.id)。
不难看出，这种方式将需要连接的两张表中的列都放到内存中，然后进行排序，而排序是一个消耗资源的操作，这样对于两张比较大的表，性能恐怕会比较差。
所以， 这种策略适合于表比较小， 或者在连接列上有索引的表。因为索引列已经排过序了。
- Nested loops
选定一张表做为驱动表，Oracle会遍历驱动表中的每一行，根据连接条件去匹配第二张表中的行。
比如第一张表中有50行数据， 第二张表中有100行数据， 这样遍历的时间约等于50100+50磁头切换时间
如果选择第二张表作为驱动表，遍历时间约等于10050+100磁头切换时间。
可见使用小表作为驱动表可以减少I/O，性能会比较好。
例如:
select from t1 inner join t2 on t1.id=t2.id
以上的这个hint 代表的是按照sql中指定的表顺序进行连接。也就是我把t1作为驱动表(Driving table).
Orace会根据t1中的每一行， 去寻找t2中满足t1.id=t2.id的行，然后返回到结果集。
不难看出， 如果在内部表的查询列上有索引的话， 查询的效率将提升。
据说，对于可并行执行的大表， 使用分区了的大表作为Driving table，性能会比较好，因为会在每个分区上并行执行，但是取决于硬件是否支持多个磁盘，多个CPU并行执行，这个我并没有试过，所以不敢妄加定论。
- Hash Join
仅针对CBO有效。
使用较小的Row source 作为Hash table和Bitmap. 而第二个row source被hashed，根据bitmap与第一个row source生成的hash table 相匹配，bitmap查找的速度极快。
例如:
select * from t1 inner join t2 on t1.id=t2.id
特别的，当Hash Table很大而不能全部留存在内存中的时候，这种Join策略更为实用。
但是，由于Bitmap本身的限制， 这种join策略只适用在等值连接的情况下。
而且，在计算Hash Table的时候， 需要考虑系统Hash_Area_Size参数设置。
show parameter hash_area_size