Hash Join（哈希連接）

在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
Nest Loop Join	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操作的性能。

Hash Join是Oracle CBO時代經常出現的一種連接方式，對海量數據處理時經常出現在執行計劃裏。本篇的上篇（http://space.itpub.net/17203031/viewspace-697442） 介紹了Hash Join的一些外部特徵和操作算法流程，下面我們一起看下一些影響到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

 

 

該參數的隱式化，也就說明了CBO已經成熟到一定程度，Oracle官方不希望我們禁用掉這種Hash Join連接方式。當然，我們可以從system和session兩層均可以暫時的禁用掉hash Join。

 

//此時_hash_join_enable=true

SQL> explain plan for select * from segs, tabs where segs.segment_name=tabs.table_name;

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

Plan hash value: 2106473715

---------------------------------------------------------------------------

| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |

---------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |      |   990 |   354K|    25   (4)| 00:00:01 |

|*  1 |  HASH JOIN         |      |   990 |   354K|    25   (4)| 00:00:01 |

|   2 |   TABLE ACCESS FULL| TABS |   968 |   229K|    11   (0)| 00:00:01 |

|   3 |   TABLE ACCESS FULL| SEGS |  2267 |   274K|    13   (0)| 00:00:01 |

---------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   1 - access("SEGS"."SEGMENT_NAME"="TABS"."TABLE_NAME")

15 rows selected

//session層面禁用hash_join連接

SQL> alter session set "_hash_join_enabled"=false;

Session altered

 

NAME                 VALUE      DESCRIB

-------------------- ---------- ------------------------------

_hash_join_enabled   FALSE      enable/disable hash join

 

//相同的SQL，此時參數環境已經變化；

SQL> explain plan for select * from segs, tabs where segs.segment_name=tabs.table_name;

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

---------------------------------------------------------------------------------------------------

Plan hash value: 3475644097

 

------------------------------------------------------------------------------------

| Id  | Operation           | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |

------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT    |      |   990 |   354K|       |   144   (2)| 00:00:02 |

|   1 |  MERGE JOIN         |      |   990 |   354K|       |   144   (2)| 00:00:02 |

|   2 |   SORT JOIN         |      |   968 |   229K|   712K|    65   (2)| 00:00:01 |

|   3 |    TABLE ACCESS FULL| TABS |   968 |   229K|       |    11   (0)| 00:00:01 |

|*  4 |   SORT JOIN         |      |  2267 |   274K|   824K|    79   (2)| 00:00:01 |

|   5 |    TABLE ACCESS FULL| SEGS |  2267 |   274K|       |    13   (0)| 00:00:01 |

------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   4 - access("SEGS"."SEGMENT_NAME"="TABS"."TABLE_NAME")

       filter("SEGS"."SEGMENT_NAME"="TABS"."TABLE_NAME")

已選擇18行。

 

可見，當我們session級別禁用了hash Join連接之後，CBO不能進行Hash Join路徑選擇。於是選擇了Merge Join路徑，顯然無論是執行時間還是CPU成本，Merge Join略遜一籌。

 

ü        Hash_Area_Size

 

Hash Join操作是依賴獨立的私有空間，我們稱之爲Hash_Area。Hash Area在Join過程中的作用就是將連接小表儘可能的緩存在Hash Area中，供進行Hash匹配和Bucket內部精確匹配。Hash Area是貯存在PGA中，屬於會話session獨立的一塊空間。如果Hash Area較小，不足以存放小表全部數據，就會引起Temp表空間的使用，進而影響Hash Join性能。

 

SQL> show parameter hash

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

hash_area_size                       integer     131072

 

 

因爲每一個會話都會開啓一個Hash Area進行Hash 操作，所以通常Hash Area的大小不會設置很大。與Hash Area類似的空間是Sort Area，用於進行SQL語句中的Order by操作，也是一個依賴分配的參數項目。通常，Hash Area被分配大小爲Sort Area的兩倍。

 

 

SQL> show parameter sort_area

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

sort_area_retained_size              integer     0

sort_area_size                       integer     65536

 

 

進入Oracle 9i之後，特別是10g出現，Oracle共享內存和獨佔內存分配策略呈現自動化和自適應化的趨勢，而且這種技術也逐漸成熟。DBA只需要確定Oracle數據庫總的內存使用大小（memory_target），就會根據算法、負載不斷調整實現自適應的內存分區調整。

 

作爲PGA分配，Oracle推出的自動調控參數是pga_aggregate_target，表示所有會話的PGA總分配大小。如果不啓用PGA自動分配，該參數值就是設置爲0。

 

SQL> show parameter pga

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

pga_aggregate_target                 big integer 0

 

 

 

ü        Hash_multiblock_io_count

 

該參數表示在進行Hash Join連接操作的時候，一次可以讀取的塊個數。在最新的版本中，該參數已經變成了一個隱含參數。

 

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_multiblock%';

 

NAME                           VALUE      DESCRIB

------------------------------ ---------- ------------------------------

_hash_multiblock_io_count      0          number of blocks hash join wil

                                          l read/write at once

 

 

這個參數可以追溯到Oracle 8i時代，當時設置的默認值爲1。在以後的版本中，通常設置爲0。這個參數對IO影響重大，不同的硬件環境、系統負載下效果不同。所以，當設置爲0的時候，Oracle是會每次自動計算該值。

 

作爲我們來講，最好不要進行該參數的設置。

 

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的綜合效率很高，特別在海量數據時代。