java多表查詢用什么聯接

本篇內容介紹了“java多表查詢用什么聯接”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

我們分析三種常見的join: Merge join，Hash join 和 NestedLoop Join。在此之前，我們先介紹一些關鍵詞：

Inner ralation 和 outer relation。

一個 relation 可以是

• 一張表

• 一個索引

• 一個前面操作的中間結果

當你在對兩個 relation 進行 Join 的時候，join 算法對inner 和 outer relation 的方式是有區別的。outer relation 是左數據集， inner relation 是右數據集。

比如說 A JOIN B，此時 A 是 outer relation，B 是 inner relation。而且一般 A JOIN B 和 B JOIN A 用時是不一樣的。

后面我們假設 outer relation 有 N 個元素， inner relation 有 M個元素。不過實際的優化器里，可以從統計信息中拿到確切的值。

Nested loop join

嵌套關聯是最容易的一個。過程大概是：

• 遍歷 outer relation 的每一行

• 然后去查找inner relation 的每一行是否匹配

寫成偽代碼是這樣：

nested_loop_join(array outer, array inner)

  for each row a in outer

    for each row b in inner

      if (match_join_condition(a,b))

        write_result_in_output(a,b)

      end if

    end for

   end for

因為兩重遍歷，所以復雜度是 O(N*M)。對應到磁盤的I/O，在outer relation中，N 行中的每一行，都需要從inner relation 中循環讀取M行數據。

所以這個算法需要從磁盤讀 N + N*M行數據。但是，如果 inner relation 足夠小，可以放到內存里的話，就只需要讀 M + N 次了。雖然說在時間復雜度上沒什么變化，但在磁盤I/O上這個方式還不錯，因此， inner relation 可以被索引替代，磁盤I/O也更有利。

Hash join

哈希連接更復雜，不過很多時候也比循環嵌套連接成本要低

哈希連接的原理是：

• 從 inner relation 中獲取所有元素

• 保存哈希表到磁盤

• 在內存中建立一個哈希表

• 逐條讀取outer relation 的所有元素

• （用哈希表的哈希函數）計算每個元素的哈希值，來查找inner relation 關聯的哈希桶

• 查看 outer relation 的元素是否有哈希桶內的匹配。

在時間復雜度方面我們需要做點假設簡化問題：

• inner relation 被劃分成 X 個哈希桶

• 哈希函數接近均勻地分布每個 relation 內數據的哈希值，相當于說哈希桶大小是一致的。

• outer relation 的元素與哈希桶內的所有元素的匹配，成本是哈希桶內元素的數量。

時間復雜度是 (M/X) * N + cost_to_create_hash_table(M) + cost_of_hash_function*N。如果哈希函數創建了足夠小規模的哈希桶，那么復雜度就是 O(M+N)。

還有個哈希聯接的版本，對內存更友好，但是對磁盤 I/O 不夠有利。情況是這樣的：

• 計算outer relation 和 inner relation 雙方的哈希表

• 保存哈希表到磁盤

• 然后逐個比較兩個 relation 的哈希桶（一個關系讀到內存里，另一個逐行讀取）

Merge join

合并聯接是唯一產生排序的聯接算法。

注：這個簡化的合并聯接不區分內表或外表；兩個表扮演同樣的角色。但實際實現方式是不同的，比如當處理重復值時。

1.（可選）排序聯接運算：兩個輸入源都按照聯接關鍵字排序。

2. 合并聯接運算：排序后的輸入源合并到一起。

排序

我們已經說過合并排序，在這里合并排序是個很好的算法。

有些時候數據集已經排序了，比如：

• 如果表內部就是有序的，比如聯接條件里有一個索引組織表

• 如果 relation 是聯接條件里的一個索引

• 如果聯接是作用在一個已經排序的查詢的中間結果

合并聯接

這部分與我們說過的合并排序中的合并運算非常相似。區別只在于我們不從兩個關系里挑選所有元素，只選相同的元素。

大致原理如下：

• 在兩個 relation 里，比較當前元素（當前的等號第一次出現）

• 相同的時候，就把兩個元素都放到結果里，再比較兩個關系里的下一個元素

• 不相同的話，就去帶有最小元素的關系里找下一個元素

• 重復 1、2、3步驟直到其中一個關系的最后一個元素。

因為兩個關系都是已排序的，你不再需要「回過頭找」，所以這個方法很有效。

這個算法是個簡化版本，它沒有處理兩組數據中相同數據出現多次的情況。

哪個連接算法最好？

如果有最好的，就沒必要弄那么多種類型了。由于很多因素要考慮，所以不會有一個簡單的答案，需要考慮的因素例如這些：

• 空閑內存大小：沒有足夠的內存的話，就和有力的哈希聯接，至少是完全內存中哈希聯接 說bye bye吧。

• 兩個數據集的大小：如果一個大表聯接一個很小的表，嵌套循環聯接就比哈希聯接要快，因為后者有創建哈希的成本；如果兩個表都非常大，那么嵌套循環聯接CPU成本就很高。

• 是否有索引：有兩個 B+樹索引的話，合并聯接似乎是更聰明的選擇。

• 結果集是否需要排序：即使你用到的是無序的數據集，你也可能想用成本較高的合并聯接（帶排序的），因為最終的結果是有序的，你可以把它和另一個結果集通過合并聯接合起來（也可能查詢用的 ORDER BY/GROUP BY/DISTINCT 等操作符隱式或顯式地要求一個排序結果）。

• 關系是否已經排序：這時候合并聯接是最佳的選擇。

• 聯接的類型：是等值聯接（比如 tableA.col1 = tableB.col2 ）還是內聯接？外聯接？笛卡爾乘積？或者自聯接？有些聯接在特定環境下是無法工作的。

• 數據的分布：假如聯接條件的數據是傾斜的（比如根據姓氏來聯接人，會有很多同姓的人），用哈希聯接將是個災難，因為是哈希函數將產生分布極不均勻的哈希桶。

• 如果你希望聯接操作使用多線程或多進程。

“java多表查詢用什么聯接”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！