簡體 English 中英

加入查詢或子查詢

[英]Join query or subquery

原文 2009-03-18 14:31:04 3 8 sql/ join/ subquery

開發人員何時使用聯接而不是子查詢是否有經驗法則，或者它們是否相同。

8 個解決方案

第一個原則是“准確地陳述查詢”。 第二個原則是“簡單明了地陳述查詢”（這是您通常做出選擇的地方）。 第三個是“說明查詢，以便有效處理”。

如果它是一個具有良好查詢處理器的 dbms，那么等效的查詢設計應該會產生相同的查詢計划（或至少同樣有效）。

第一次使用 MySQL 時，我最大的挫敗感是我必須有意識地預測優化器。 在長期使用 Oracle、SQL Server、Informix 和其他 dbms 產品后，我很少會擔心自己會遇到此類問題。 現在使用較新版本的 MySQL 會更好，但我最終還是需要比其他人更頻繁地關注它。

在性能方面，它們在大多數現代數據庫引擎中沒有任何區別。

子查詢的問題是您可能會在沒有任何鍵的情況下結束子結果集，因此加入它們會更昂貴。

如果可能，請始終嘗試使用 ON 子句而不是 WHERE 進行 JOIN 查詢和過濾（盡管它應該是相同的，因為現代引擎為此進行了優化）。

理論上，每個子查詢都可以更改為連接查詢。

取決於關系數據庫管理系統。 您應該比較兩個查詢的執行計划。

根據我對 Oracle 10 和 11 的經驗，執行計划總是相同的。

與許多事情一樣，這取決於。 - 子查詢有多復雜 - 在查詢中子查詢多久執行一次

我盡量避免子查詢。 尤其是當期望大的結果集永遠不要使用子查詢時——以防子查詢是針對結果集的每個項目執行的。

保重，亞歷克斯

現在讓我們忽略性能影響（如果我們知道“過早的優化是萬惡之源”，我們應該這樣做）。

選擇看起來更清晰、更易於維護的內容。

在 SQL 服務器中，相關子查詢的性能通常比連接更差，或者性能甚至更好，連接到派生表。 我幾乎從不為必須多次執行的任何事情編寫子查詢。 這是因為相關子查詢通常基本上將您的查詢轉換為 cursor 並一次運行一行。 在數據庫中，通常最好以基於集合的方式做事