在作表join的时候， Oracle有三种方式， 与其说有三种方式， 不如说是三种策略。 sql
分别是： oracle
根据个人理解来说讲这三种策略。 oop
首先讲讲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. spa
总之， Row source是oracle根据执行计划生成的可操做数据集, 这种说法比Table更为严谨，由于join的两侧多是view或者其余的object. code
1) 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)。
不难看出，这种方式将须要链接的两张表中的列都放到内存中，而后进行排序，而排序是一个消耗资源的操做，这样对于两张比较大的表，性能恐怕会比较差。
因此， 这种策略适合于表比较小， 或者在链接列上有索引的表。由于索引列已经排过序了。
2) Nested loops
选定一张表作为驱动表，Oracle会遍历驱动表中的每一行，根据链接条件去匹配第二张表中的行。
好比第一张表中有50行数据， 第二张表中有100行数据， 这样遍历的时间约等于50*100+50*磁头切换时间
若是选择第二张表做为驱动表，遍历时间约等于100*50+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并行执行，这个我并无试过，因此不敢妄加定论。
3) 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