哪一個更有效率：2個單表查詢或1個連接查詢

Question

說tableA有1行要返回，但將返回100列，而tableB有100行要返回，但每個行只有一列。 TableB有一個用於表A的外鍵。

將tableA和tableB的左連接返回100 * 100個數據單元，而2個單獨的查詢返回100 + 100個單元的數據或50次的數據，或者是誤解怎麼運行的？

使用許多簡單的查詢而不是更簡單的查詢會更高效嗎？

Answer 1

首先，我會質疑一個有100列的表格，並建議您的模式可能有更好的設計。在現實世界中，這個列的數量不太常見，所以通常一個查詢返回的數據量與兩個查詢返回的數據量的差異變得不那麼重要。表中的100列並不一定是壞的，只是一個可以考慮的標誌。

但是，假設你的數字是他們是什麼弄清楚的問題，都需要考慮的幾個重要變量：

1 - 什麼是數據庫服務器和應用服務器之間的鏈接速度？如果速度非常慢，那麼最好儘量減少返回的數據量與運行的查詢數量。如果速度不慢，那麼在執行兩個查詢時，您可能會花費更多時間，而不是返回增加的有效負載。哪一個更好只能通過在你自己的環境中進行測試來確定。

2 - 傳輸協議本身的效率如何？也許有某種數據壓縮，或者知道第2列到第101列的更聰明的算法對於每一行都是重複的，所以它只會傳遞一次。運輸協議中的這種策略可以緩解您的任何擔憂。再次，這就是爲什麼你需要在自己的環境中進行測試以確定知道。正如其他人所指出的那樣，你也需要考慮一旦你得到數據會做什麼（例如JOINs，GROUPing等），但是我限制了我對你的問題的具體細節的迴應計數與有效載荷大小。

Answer 2

我認爲你的問題基本上是關於database normalization。通常，建議將數據庫規範化爲多個表（使用主鍵和外鍵），並在查詢時根據需要將它們連接起來。這對於插入/更新性能和保持數據一致性更好，並且通常也會導致更小的數據庫大小。

至於返回的行號，只有交叉連接實際上會返回100 * 100行;任何內部或外部連接都不會創建所有組合，而是將給定條件下的行連接在一起，而對於外部連接則保留無法匹配的行。維基百科在其JOIN article中有一些樣本。

對於查詢量非常大的應用程序，性能可能在使用較少規範化表格時效果會更好。不過，如同優化一樣，我只會考慮在看到真正可衡量的問題（例如使用分析工具）後進入該方向。

一般來說，儘量保持數據庫往返的次數少;大量的單個簡單查詢將遭受與DB引擎（網絡等）交談的開銷。如果您需要執行復雜的一系列語句，請考慮使用存儲過程。

Answer 3

什麼是最好的加入？數據庫引擎或客戶端代碼？說，我使用這兩種技術：它取決於客戶端和如何使用數據。

• 這裏的數據需要一些處理，比如說，在網頁上渲染我可能會拆分標題和細節記錄集。我們這樣做是因爲我們在數據庫和HTML之間有一些業務邏輯

• 在簡單線性消耗的地方，我會加入數據庫以避免不必要的處理。例如，簡單的報告或出口

Answer 4

這取決於，如果你只考慮到SQL效率obviusly幾個簡單和更小的結果的查詢效率會更高。 但是，如果在客戶端上進行連接，或者需要在連接後過濾結果，則需要考慮整個過程，那麼在代碼上執行該操作可能會更有效。

編碼通常是不同系統，數據庫與客戶端，內存與CPU之間的權衡......您需要對此有意識並嘗試找到完美的解決方案。

在這種情況下，大概2個查詢優於1，但這不是一個通用的解決方案。

Answer 5

只要查詢返回的是實際相關的數據，通常只有較少的查詢會提高性能。試圖將不相關的數據放入同一個查詢中以減少數量或查詢沒有意義。

當然有例外，你的例子可能是其中之一。然而，這取決於返回領域的數量，比如領域實際返回的數量，即實際的數據量。

作爲查詢數量如何影響性能的一個例子，我可以提到一個解決方案，我已經（很遺憾地）看過很多次。在這種解決方案中，程序員首先會從一個表中獲取大量記錄，然後遍歷記錄並對每個記錄運行另一個查詢以從另一個表中獲取相關記錄。這顯然導致了很多查詢，而具有一個或兩個查詢的解決方案將更有效率。

Answer 6

「是前所未有的高效率使用許多簡單的查詢，而不是更少的更復雜的？」

，要求數據穿過的最低金額，併爲您提供不超過你所需要的查詢是效率更高。除此之外，RDBMS特定的條件可以在一個RDBMS系統上比另一個更高效。在非常低的水平上，當處理更少的數據時，可以更快地檢索結果，因此高效的查詢只能使用最少量的數據來處理查詢結果。