oracle錶鏈接方式對比實例

在Oracle中，肯定鏈接操做類型是執行計劃生成的重要方面。各類鏈接操做類型表明着不一樣的鏈接操做算法，不一樣的鏈接操做類型也適應於不一樣的數據量和數據分佈狀況。

 

 

不管是Nest Loop Join（嵌套循環），仍是Merge Sort Join（合併排序鏈接），都是適應於不一樣特殊狀況的古典鏈接方法。Nest Loop Join算法雖然能夠藉助鏈接列索引，可是帶來的隨機讀成本過大。而Merge Sort Join雖然能夠減小隨機讀的狀況，可是帶來的大規模Sort操做，對內存和Temp空間壓力過大。兩種算法在處理海量數據的時候，若是是海量隨機讀仍是海量排序，都是不能被接受的鏈接算法。本篇中，咱們介紹目前比較經常使用的一種鏈接方式Hash Join鏈接。

 

 

一、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的各類特性。

 

 

二、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操做的性能。