深入探討DB2表連接原理
DB2表連接操作是我們經常可以見到的，下文對DB2表連接原理作了詳盡的闡述分析，如果您對此方面感興趣的話，不妨一看。
在DB2中，優化器可以選擇嵌套連接或合并連接，如果得到正確支持的話，還可以選擇散列連接。如果系統調優得正確，散列連接可顯著提高某些查詢的性能。DB2優化器可以在執行連接時選擇不同方法：在缺省情況下，它在嵌套循環連接（nested loop join）與合并連接（merge join）之間選擇。當設置了特殊環境變量時，它還可以選擇散列連接（hash join）。
兩個表之間的連接是這樣操作的：將一個表中的行與另一個表中的行并置在一起。另外，可以指定條件以定義并置哪些行。為執行這一操作，DB2 可以選擇不同的連接方法。在連接兩個表時，無論使用哪種連接方法，總有一個表被選為外表（outer table）而另一個表被選為內表（inner table）。優化器根據所選連接方法的成本和類型決定哪個是外表、哪個是內表。首先訪問外表，并且只掃描一次。根據連接的類型和存在的索引，可以多次掃描內表。還有一點也很重要，要記住即使您試圖連接兩個以上的表，優化器也將每次只連接兩個表，并在必要時保存中間結果。要理解散列連接方法的優勢，先理解其它連接方法的工作原理也很重要。
嵌套循環連接
正如我們前面提到的那樣，外表只被掃描一次。對于嵌套循環連接，要在內表中找到與外表中每一行相匹配的行有兩種方法：
掃描內表。即，讀取內表中的每一行，并且針對該行決定是否應將其與正在考慮的外表中的行相連接。
對內表上的連接列進行索引查找。當用于連接的謂詞所包含的列在內表的索引中時，這種方法是可行的。這極大地減少了在內表中訪問的行數。
在嵌套循環連接中，決定哪個是外表、哪個是內表非常重要，因為外表只掃描一次，而針對外表中的每一行，都要訪問一次內表。正如前面提到的那樣，優化器用成本模型來決定誰是外表誰是內表。優化器做此決定時會考慮幾個因素：
表的大小
緩沖
謂詞
排序要求
是否存在索引
連接列不能是 LONG 或 LOB 字段。
合并連接
合并連接需要一個等式連接謂詞（即具有 table1.column = table2.column 格式的謂詞）。它還要求根據連接列對輸入表進行排序。通過掃描現有索引或在進行連接之前對表進行排序就可以做到這一點。連接列不能是 LONG 或 LOB 字段。
同時掃描兩個表，以查找匹配行。外表和內表都只掃描一次，除非外表中有重復的值，那樣的話可能要再次掃描內表的某些部分。因為表通常只被掃描一次，所以決定哪個是外表、哪個是內表不象在其它連接方法中那么重要。盡管如此，由于可能有重復的值，所以優化器通常選擇重復值較少的表作為外表。但是，優化器最終還是使用成本模型來決定誰是外表誰是內表。
散列連接
散列連接需要一個或多個等式連接謂詞，其中每個謂詞的列類型相同。就 CHAR 類型而言，長度必須相同。就 DECIMAL 類型而言，精度和小數位必須相同。同樣，連接列不能是 LONG 或 LOB 字段。散列連接可處理多個等式謂詞這一事實相對于合并連接是一大優勢，后者只能處理一個等式謂詞。
對于散列連接，首先掃描內表（也稱為構建表，bulid table），表中的行被復制到內存緩沖區。根據“散列代碼（hash code）”，這些緩沖區被分為幾個分區，散列代碼是根據連接謂詞中的列計算出來的。如果內存中沒有足夠的空間容納整個表，則有些分區被寫入磁盤上的臨時表。然后掃描外表（稱為探測表，probe table）。對于探測表中的每一行，對連接列應用同一散列算法。如果所獲得的散列代碼與構建行的散列代碼相匹配，則比較實際的連接列。如果與探測表行匹配的分區在內存中，則比較會立即進行。如果分區被寫入臨時表，則探測行也被寫入臨時表。最后，處理包含同一分區中的行的臨時表以進行匹配。
由于將構建表保存在內存中所具有的好處，優化器通常選擇較小的表作為構建表，以避免必須將該表溢出（spill）到磁盤上。但是，要再次強調的是，成本模型最終決定哪個表是內表、哪個表是外表。
選擇哪種連接方法？
到目前為止，我們已經討論了在DB2中可用的不同連接方法。正如我們所知，初看起來，某些方法與其它方法相比是更好的選擇。例如，與根據外表的每一行掃描內表的嵌套循環連接相比，合并連接具有只對表掃描一次的優勢。于是，合并連接似乎是一個更好的選擇；但是，如果存在索引的話，則嵌套循環會是更好的選擇。
同樣地，與合并連接相比，散列連接似乎是更好的選擇，因為它不需要在執行前對輸入表排序，但如果我們需要保持外表中行的次序，則合并連接或嵌套循環連接可能是更好的選擇 — 散列連接不能保證維持次序，因為它可能溢出到磁盤而那樣會破壞次序。
【編輯推薦】
