from：http://trophy.iteye.com/blog/1416410
在Oracle中，確定連接操作類型是執行計劃生成的重要方面。各種連接操作類型代表着不同的連接操作算法，不同的連接操作類型也適應於不同的數據量和數據分佈情況。
無論是Nest Loop Join（嵌套循環），還是Merge Sort Join（合併排序連接），都是適應於不同特殊情況的古典連接方法。
Nest Loop Join算法雖然可以藉助連接列索引，但是帶來的隨機讀成本過大。
而Merge Sort Join雖然可以減少隨機讀的情況，但是帶來的大規模Sort操作，對內存和Temp空間壓力過大。兩種算法在處理海量數據的時候，如果是海量隨機讀還是海量排序，都是不能被接受的連接算法。本篇中，我們介紹目前比較常用的一種連接方式Hash Join連接。
1、Hash Join（哈希連接）原理
從Oracle 7.3開始，Hash Join正式進入優化器執行計劃生成，只有CBO才能使用Hash Join操作。本質上說，Hash Join連接是藉助Hash算法，連帶小規模的Nest Loop Join，同時利用內存空間進行高速數據緩存檢索的一種算法。
下面我們分步驟介紹Hash Join算法步驟：
i. Hash Join連接對象依然是兩個數據表，首先選擇出其中一個“小表”。這裏的小表，就是參與連接操作的數據集合數據量小。對連接列字段的所有數據值，進行Hash函數操作。Hash函數是計算機科學中經常使用到的一種處理函數，利用Hash值的快速搜索算法已經被認爲是成熟的檢索手段。Hash函數處理過的數據特徵是“相同數據值的Hash函數值一定相同，不同數據值的Hash函數值可能相同”；
ii. 經過Hash處理過的小表連接列，連同數據一起存放到Oracle PGA空間中。PGA中存在一塊空間爲hash_area，專門存放此類數據。並且，依據不同的Hash函數值，進行劃分Bucket操作。每個Bucket中包括所有相同hash函數值的小表數據。同時建立Hash鍵值對應位圖。
iii. 之後對進行Hash連接大表數據連接列依次讀取，並且將每個Hash值進行Bucket匹配，定位到適當的Bucket上（應用Hash檢索算法）；
iv. 在定位到的Bucket中，進行小規模的精確匹配。因爲此時的範圍已經縮小，進行匹配的成功率精確度高。同時，匹配操作是在內存中進行，速度較Merge Sort Join時要快很多；
下面是一個Hash Join的執行計劃。
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 779051904
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2617 | 572K| 142 (1)| 00:00:02 |
|* 1 | HASH JOIN | | 2617 | 572K| 142 (1)| 00:00:02 |
| 2 | TABLE ACCESS FULL| SEGS | 2503 | 312K| 16 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| OBJTS | 31083 | 2914K| 126 (1)| 00:00:02 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")
從原理過程來看，Hash Join與Nest Loop Join/Merge Sort Join存在一定相似度。
首先，Hash Join同Nest Loop Join一樣，進行一定的嵌套循環匹配操作，不過差異在於匹配進行隨機讀的範圍是受限範圍。不會像Nest Loop Join一樣直接頻繁進行全表規模的隨機讀。
其次，Hash Join同之前介紹過的Merge Sort Join有相似點，都是利用PGA的空間進行獨立操作。Hash Join中的Bucket就是保存在內存的PGA中，有一塊專門Hash_Area進行該項操作。選擇小表作爲驅動連接表，就是儘量爭取PGA內存中可以完全裝下小表數據，儘量不要使用Temp表空間。這樣，進行Hash匹配和精確匹配的速度就是有保證的。
最後，Hash Join使用的場景是有限制的。其中最大的一個就是連接操作僅能使用“=”連接。因爲Hash匹配的過程只能支持相等操作。還有就是連接列的數據分佈要儘量做到數據分佈均勻，這樣產生的Bucket也會儘可能均勻。這樣限制匹配的速度纔有保證。如果數據列分佈偏移嚴重，Hash Join算法效率會有退化趨勢。
隨着系統數據量的不斷增加，出現Hash Join的場景就會越來越多。下面通過一系列實驗來確定Hash Join的各種特性。
2、Hash Join連接實驗
首先是準備實驗環境。
SQL> create table segs as select * from dba_segments where wner='SYS';
Table created
SQL> create table objts as select * from dba_objects where wner='SYS';
Table created
SQL> select count(*) from segs;
COUNT(*)
----------
2503------小表
SQL> select count(*) from objts;
COUNT(*)
----------
31083------大表
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
此時，我們對比三種連接方式的成本因素。
SQL> set autotrace traceonly;
SQL> select * from segs, objts where segs.segment_name=objts.object_name;
已選擇4870行。
執行計劃
----------------------------------------------------------
Plan hash value: 779051904
----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2617 | 572K| 142 (1)| 00:00:02 |
|* 1 | HASH JOIN | | 2617 | 572K| 142 (1)| 00:00:02 |
| 2 | TABLE ACCESS FULL| SEGS | 2503 | 312K| 16 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| OBJTS | 31083 | 2914K| 126 (1)| 00:00:02 |
----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")
統計信息
----------------------------------------------------------
1 recursive calls
0 db block gets
814 consistent gets
0 physical reads
0 redo size
356347 bytes sent via SQL*Net to client
3940 bytes received via SQL*Net from client
326 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4870 rows processed
SQL> select/*+use_nl(segs,objts)*/*from segs, objts where segs.segment_name=objts.object_name;
已選擇4870行。
執行計劃
----------------------------------------------------------
Plan hash value: 2045044449
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2617 | 572K| 5023 (1)| 00:01:01 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2617 | 572K| 5023 (1)| 00:01:01 |
| 3 | TABLE ACCESS FULL | SEGS | 2503 | 312K| 16 (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")
統計信息
----------------------------------------------------------
1 recursive calls
0 db block gets
5799 consistent gets
0 physical reads
0 redo size
406352 bytes sent via SQL*Net to client
3940 bytes received via SQL*Net from client
326 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4870 rows processed
SQL> select/*+use_merge(segs,objts)*/*from segs, objts where segs.segment_name=objts.object_name;
已選擇4870行。
執行計劃
----------------------------------------------------------
Plan hash value: 2272228973
-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2617 | 572K| | 900 (1)| 00:00:11|
| 1 | MERGE JOIN | | 2617 | 572K| | 900 (1)| 00:00:11 |
| 2 | SORT JOIN | | 2503 | 312K| 920K| 90 (2)| 00:00:02 |
| 3 | TABLE ACCESS FULL| SEGS | 2503 | 312K| | 16 (0)| 00:00:01 |
|* 4 | SORT JOIN | | 31083 | 2914K| 8168K| 809 (1)| 00:00:10 |
| 5 | TABLE ACCESS FULL| OBJTS | 31083 | 2914K| | 126 (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")
統計信息
----------------------------------------------------------
1 recursive calls
0 db block gets
494 consistent gets
0 physical reads
0 redo size
427743 bytes sent via SQL*Net to client
3940 bytes received via SQL*Net from client
326 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
4870 rows processed
詳細對比見下圖：
|
|
塊讀 |
排序 |
CPU成本 |
執行時間 |
|
Hash Join |
814 |
0 |
142 |
0.02 |
|
NestLoopJoin |
5799 |
0 |
5023 |
1.01 |
|
Merge Sort Join |
494 |
2 |
900 |
0.11 |
三種連接方式，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操作的性能。
附錄：
Oracle數據庫中的優化器又叫查詢優化器（Query Optimizer）。它是SQL分析和執行的優化工具，它負責生成、制定SQL的執行計劃。Oracle的優化器有兩種，基於規則的優化器（RBO）與基於代價的優化器（CBO)
RBO: Rule-Based Optimization 基於規則的優化器
CBO: Cost-Based Optimization 基於代價的優化器
RBO自ORACLE 6以來被採用，一直沿用至ORACLE 9i. ORACLE 10g開始，ORACLE已經徹底丟棄了RBO，它有着一套嚴格的使用規則，只要你按照它去寫SQL語句，無論數據表中的內容怎樣，也不會影響到你的“執行計劃”，也就是說RBO對數據不“敏感”；它根據ORACLE指定的優先順序規則，對指定的表進行執行計劃的選擇。比如在規則中，索引的優先級大於全表掃描;RBO是根據可用的訪問路徑以及訪問路徑等級來選擇執行計劃，在RBO中，SQL的寫法往往會影響執行計劃，它要求開發人員非常瞭解RBO的各項細則，菜鳥寫出來的SQL腳本性能可能非常差。隨着RBO的被遺棄，漸漸不爲人所知。也許只有老一輩的DBA對其瞭解得比較深入。關於RBO的訪問路徑，官方文檔做了詳細介紹：