快速了解Oracle哈希連接

在向大家詳細介紹Oracle哈希連接之前，首先讓大家了解下Oracle讀取row source，然後全面介紹Oracle哈希連接，希望對大家有用。在NESTED LOOPS連接中，Oracle讀取row source1中的每一行，然後在row sourc2中檢查是否有匹配的行，所有被匹配的行都被放到結果集中，然後處理row source1中的下一行。

這個過程一直繼續，直到row source1中的所有行都被處理。這是從連接操作中可以得到第一個匹配行的最快的方法之一，這種類型的連接可以用在需要快速響應的語句中，以響應速度為主要目標。

如果driving row source(外部表)比較小，並且在inner row source(內部表)上有唯一索引，或有高選擇性非唯一索引時，使用這種方法可以得到較好的效率。NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返回數據，這可以實現快速的響應時間。

如果不使用並行操作，最好的驅動表是那些應用了where 限制條件後，可以返回較少行數據的的表，所以大表也可能稱為驅動表，關鍵看限制條件。對於並行查詢，我們經常選擇大表作為驅動表，因為大表可以充分利用並行功能。當然，有時對查詢使用並行操作並不一定會比查詢不使用並行操作效率高，因為最後可能每個表只有很少的行符合限制條件，而且還要看你的硬件配置是否可以支持並行(如是否有多個CPU，多個硬盤控制器)，所以要具體問題具體對待。

NL連接的例子：

SQL> explain plan for  
select a.dname,b.sql  
from dept a,emp b  
where a.deptno = b.deptno;  
Query Plan  
SELECT STATEMENT [CHOOSE] Cost=5 
NESTED LOOPS  
TABLE Access FULL DEPT [ANALYZED]  
TABLE Access FULL EMP [ANALYZED] 

Oracle哈希連接(Hash Join, HJ)

這種連接是在Oracle 7.3以後引入的，從理論上來說比NL與SMJ更高效，而且只用在CBO優化器中。

較小的row source被用來構建hash table與bitmap，第2個row source被用來被hansed，並與第一個row source生成的hash table進行匹配，以便進行進一步的連接。Bitmap被用來作為一種比較快的查找方法，來檢查在hash table中是否有匹配的行。特別的，當hash table比較大而不能全部容納在內存中時，這種查找方法更為有用。這種連接方法也有NL連接中所謂的驅動表的概念，被構建為hash table與bitmap的表為驅動表，當被構建的hash table與bitmap能被容納在內存中時，這種連接方式的效率極高。

HASH連接的例子：

SQL> explain plan for  
select /*+ use_hash(emp) */ empno  
from emp, dept  
where emp.deptno = dept.deptno;  
Query Plan  
SELECT STATEMENT [CHOOSE] Cost=3 
HASH JOIN  
TABLE Access FULL DEPT  
TABLE Access FULL EMP 

要使Oracle哈希連接有效，需要設置HASH_JOIN_ENABLED=TRUE，缺省情況下該參數為TRUE，另外，不要忘了還要設置 hash_area_size參數，以使Oracle哈希連接高效運行，因為Oracle哈希連接會在該參數指定大小的內存中運行，過小的參數會使Oracle哈希連接的性能比其他連接方式還要低。

總結一下，在哪種情況下用哪種連接方法比較好：

排序 - - 合並連接(Sort Merge Join, SMJ)：
a) 對於非等值連接，這種連接方式的效率是比較高的。
b) 如果在關聯的列上都有索引，效果更好。
c) 對於將2個較大的row source做連接，該連接方法比NL連接要好一些。
d) 但是如果sort merge返回的row source過大，則又會導致使用過多的rowid在表中查詢數據時，數據庫性能下降，因為過多的I/O。