目前为止，典型的连接类型有3种：
Sort merge join（SMJ排序－合并连接）：
首先生产driving table需要的数据，然后对这些数据按照连接操作关联列进行排序；然后生产probed table需要的数据，然后对这些数据按照与driving table对应的连接操作列进行排序；最后两边已经排序的行被放在一起执行合并操作。排序是一个费时、费资源的操作，特别对于大表。所以smj通常不是一个特别有效的连接方法，但是如果driving table和probed table都已经预先排序，则这种连接方法的效率也比较高。
Nested loops（NL嵌套循环）：
连接过程就是将driving table和probed table进行一次嵌套循环的过程。就是用driving table的每一行去匹配probed table 的所有行。Nested loops可以先返回已经连接的行，而不必等待所有的连接操作处理完成才返回数据，这可以实现快速的响应时间。
Hash join（哈希连接）：
较小的row source被用来构建hash table与bitmap，第二个row source用来被hashed，并与第一个row source生产的hash table进行匹配。以便进行进一步的连接。当被构建的hash table与bitmap能被容纳在内存中时，这种连接方式的效率极高。但需要设置合适的hash_area_size参数且只能用于等值连接中。
Cartesian product（笛卡尔积）：表的每一行依次与另外一表的所有行匹配。
_______________________________________________________
实验：
SQL> create table segs as select * from dba_segments where owner=‘SYS‘;
Table created.
SQL> create table objts as select * from dba_objects where owner=‘SYS‘;
Table created.
SQL> select count(*) from segs;
COUNT(*)
----------
2355
SQL> select count(*) from objts;
COUNT(*)
----------
30967
SQL> create index idx_segs_name on segs(segment_name);
Index created.
SQL> create index idx_objts_name on objts(object_name);
Index created.
SQL> exec dbms_stats.gather_table_stats(user,‘SEGS‘,cascade => true);
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats(user,‘OBJTS‘,cascade => true);
PL/SQL procedure successfully completed.
作用:DBMS_STATS.GATHER_TABLE_STATS统计表,列,索引的统计信息.
DBMS_STATS.GATHER_TABLE_STATS的语法如下:
DBMS_STATS.GATHER_TABLE_STATS ( ownname VARCHAR2, tabname VARCHAR2, partname VARCHAR2, estimate_percent NUMBER, block_sample BOOLEAN, method_opt VARCHAR2, degree NUMBER, granularity VARCHAR2, cascade BOOLEAN, stattab VARCHAR2, statid VARCHAR2, statown VARCHAR2, no_invalidate BOOLEAN, force BOOLEAN);
参数说明:
ownname:要分析表的拥有者
tabname:要分析的表名.
partname:分区的名字,只对分区表或分区索引有用.
estimate_percent:采样行的百分比,取值范围[0.000001,100],null为全部分析,不采样. 常量:DBMS_STATS.AUTO_SAMPLE_SIZE是默认值,由oracle决定最佳取采样值.
block_sapmple:是否用块采样代替行采样.
method_opt:决定histograms信息是怎样被统计的.method_opt的取值如下:
for all columns:统计所有列的histograms.
for all indexed columns:统计所有indexed列的histograms.
for all hidden columns:统计你看不到列的histograms
for columns <list> SIZE <N> | REPEAT | AUTO | SKEWONLY:统计指定列的histograms.N的取值范围[1,254]; REPEAT上次统计过的histograms;AUTO由oracle决定N的大小;SKEWONLY multiple end-points with the same value which is what we define by "there is skew in the data
degree:决定并行度.默认值为null.
granularity:Granularity of statistics to collect ,only pertinent if the table is partitioned.
cascace:是收集索引的信息.默认为falase.
stattab指定要存储统计信息的表,statid如果多个表的统计信息存储在同一个stattab中用于进行区分.statown存储统计信息表的拥有者.以上三个参数若不指定,统计信息会直接更新到数据字典.
no_invalidate: Does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE.
force:即使表锁住了也收集统计信息.
例子:
execute dbms_stats.gather_table_stats(ownname => ‘owner‘,tabname => ‘table_name‘ ,estimate_percent => null ,method_opt => ‘for all indexed columns‘ ,cascade => true);
------------------------------------------------------------------------------------------------------------------------
自从Oracle8.1.5引入dbms_stats包，Experts们便推荐使用dbms_stats取代analyze。 理由如下
dbms_stats可以并行分析
dbms_stats有自动分析的功能(alter table monitor )
analyze 分析统计信息的不准确some times
1,2好理解，且第2点实际上在VLDB中是最吸引人的；3以前比较模糊，看了metalink236935.1 解释，analyze在分析Partition表的时候，有时候会计算出不准确的Global statistics .
原因是，dbms_stats会实在的去分析表全局统计信息（当指定参数）；而analyze是将表分区（局部）的statistics 汇总计算成表全局statistics ,可能导致误差。
SQL> select * from segs, objts where segs.segment_name=objts.object_name;
2851 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 779051904
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2450 | 528K| 139 (1)| 00:00:02 |
|* 1 | HASH JOIN | | 2450 | 528K| 139 (1)| 00:00:02 |
| 2 | TABLE ACCESS FULL| SEGS | 2355 | 287K| 14 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| OBJTS | 30967 | 2903K| 125 (1)| 00:00:02 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
674 consistent gets
0 physical reads
0 redo size
228361 bytes sent via SQL*Net to client
2561 bytes received via SQL*Net from client
192 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2851 rows processed
SQL> select/*+use_merge(segs,objts)*/*from segs, objts where segs.segment_name=objts.object_name;
2851 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2272228973
-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2450 | 528K| | 822 (1)| 00:00:10 |
| 1 | MERGE JOIN | | 2450 | 528K| | 822 (1)| 00:00:10 |
| 2 | SORT JOIN | | 2355 | 287K| | 15 (7)| 00:00:01 |
| 3 | TABLE ACCESS FULL| SEGS | 2355 | 287K| | 14 (0)| 00:00:01 |
|* 4 | SORT JOIN | | 30967 | 2903K| 8136K| 807 (1)| 00:00:10 |
| 5 | TABLE ACCESS FULL| OBJTS | 30967 | 2903K| | 125 (1)| 00:00:02 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")
filter("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
487 consistent gets
0 physical reads
0 redo size
248233 bytes sent via SQL*Net to client
2561 bytes received via SQL*Net from client
192 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
2851 rows processed
SQL> select/*+use_nl(segs,objts)*/*from segs, objts where segs.segment_name=objts.object_name;
2851 rows selected.
Execution Plan
----------------------------------------------------------
Plan hash value: 2045044449
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2450 | 528K| 4725 (1)| 00:00:57 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2450 | 528K| 4725 (1)| 00:00:57 |
| 3 | TABLE ACCESS FULL | SEGS | 2355 | 287K| 14 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | IDX_OBJTS_NAME | 1 | | 1 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| OBJTS | 1 | 96 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
3473 consistent gets
0 physical reads
0 redo size
227906 bytes sent via SQL*Net to client
2561 bytes received via SQL*Net from client
192 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2851 rows processed
三种连接方式，SQL数据量、语句相同，最后获取不同的成本消耗。可以看出，当数据量达到万级之后，Nest Loop Join的随机读会急剧增加，带来的CPU成本和总执行时间成本也会大大增加。
而使用Merge Sort Join带来的块读是相对较少，但是付出的CPU成本和执行时间也是不可忽视的。将数据集合排序映射到内存中（可能要利用Temp Tablespace），需要消耗很大的CPU和内存资源（排序段）。
总体来说，Hash Join在这个SQL中还是能带来很好的综合性能的。只有块读稍大，其他指标都是可以接受的最好值。
下面我们介绍与Hash Join相关的一些系统参数，和Hash Join进行的三种操作模式。不同的系统参数，可能会给CBO成本运算带来影响。不同的操作模式，帮助我们理解PGA中的hash_area大小是如何影响到Hash Join操作的性能。
3、Hash Join相关参数
Hash Join是CBO优化器才能生成的执行计划操作，如果是选择了RBO就不能生成包括Hash Join的执行计划。此外，与Hash Join相关的Oracle参数还包括下面几个：
ü Hash_Join_Enable
该参数是控制CBO启用Hash Join的开关。如果设置为True，则表示CBO可以使用Hash Join连接方式，否则就不可以使用。在目前的版本中，该参数已经演化为一个隐含参数，名称为“_hash_join_enable”。
SQL> col name for a20;
SQL> col value for a10;
SQL> col DESCRIB for a30;
SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
3 WHERE x.inst_id = USERENV (‘Instance‘)
4 AND y.inst_id = USERENV (‘Instance‘)
5 AND x.indx = y.indx
6 AND x.ksppinm LIKE ‘%hash_join_enable%‘;
NAME VALUE DESCRIB
-------------------- ---------- ------------------------------
_hash_join_enabled TRUE enable/disable hash join
ü Hash_Area_Size
Hash Join操作是依赖独立的私有空间，我们称之为Hash_Area。Hash Area在Join过程中的作用就是将连接小表尽可能的缓存在Hash Area中，供进行Hash匹配和Bucket内部精确匹配。Hash Area是贮存在PGA中，属于会话session独立的一块空间。如果Hash Area较小，不足以存放小表全部数据，就会引起Temp表空间的使用，进而影响Hash Join性能。
4、连接三模式
Hash Join比较Merge Sort Join一个比较优势的地方，就是对PGA空间的有限使用上。但是，使用PGA毕竟是一种风险操作。因为Hash Area同Sort Area一样，在小表不能完全装入系统时，会调用Temp表空间的硬盘空间。这样，就会引起一些问题。
下面关于三种模式的阐述，借鉴八神前辈的《Oracle Hash Join》（http://www.alidba.net/index.php/archives/440）。特此表示感谢。
针对不同的状态，Oracle分别有不同的模式对应。
Optimal模式
这是我们进行Hash Join的最理想情况。驱动表（小表）生成的Hash数据集合可以完全存放在Hash Area的时候，我们称之为Optimal模式。
ü 首先找到驱动表，获取到驱动表。存放在Hash_Area中；
ü 在Hash Area中，对驱动表进行Hash操作，形成Hash Bulket，形成对应的分区信息。针对多个Bulket，同时形成一个Bitmap列表，做到Bulket与Bitmap位的联系；
ü 在各个Bulket中，分布着不同的数据行。如果连接列分布比较均匀，Bulket中数据也就比较均匀。如果Bulket中包括数据，对应该Bulket的Bitmap位上为1，否则为0；
ü 找被驱动表的每一列，将连接列值进行Hash处理。匹配Bitmap位，如果Bitmap为0，表示该列值没有存在，直接抛弃。否则进入Bulket进行精确匹配；
Onepass模式
如果我们设置的PGA空间小，或者连接的小表体积就已经很大了，那么就会利用到临时表空间。具体处理，就是进行两次的Hash处理，在Bulket层面的上面建立Partition分区。
当进行Hash操作的时候，出现的情形是一部分的Partition在内存中，另一部分Partition被存放在Temp表空间上。
在进行连接匹配的时候，如果能够在Bitmap中确定到Partition在内存中，那么直接在内存中进行检索和精确匹配过程。否则从Temp表空间中将对应的Partition调取到内存中，进行匹配操作。
Multipass模式
这是一种很极端的情况，如果Hash Area小到一个Partition都装不下。当进行Hash操作后，只有半个Partition能装入到Hash Area。
这种情况下，如果一个Partition匹配没有做到，还不能够放弃操作，要将剩下一半的Partition获取到进行Hash Join匹配。也就是一个Partition要经过两次的Bitmap匹配过程。
5、结论
Hash Join是一种效率很高，CBO时代很常见的连接方式。但是，相对于其他古典算法，Hash Join的综合效率很高，特别在海量数据时代。