性能 - 單個連接選擇與多個簡單選擇

Question

在性能方面哪些更好？

Answer 1

只有一種方法可以知道：時間。

一般來說，我認為單個連接使數據庫能夠進行大量優化，因為它可以看到它需要掃描的所有表，減少了開銷，並且可以在本地構建結果集。

最近，我有大約100個select語句，我在代碼中將其更改為JOIN。 通過幾個索引，我可以從1分鍾的運行時間到大約0.6秒。

Answer 2

單個連接通常優於多個單個選擇。 但是，有太多不同的案例適合您的問題。 在一個簡單的規則下將它們混為一談是不明智的。

更重要的是，如果您和下一個程序員在使用SQL時“說同一種語言”，單個連接通常會更容易讓下一個程序員理解和修改。 我在談論元組集的語言。

同樣重要的是，數據庫物理設計和查詢設計需要首先關注的問題將導致十分之一的速度改進，而不是10％的速度改進。 如果你做了數以千計的簡單選擇而不是單個連接，那么你可能會獲得十分之一的優勢。 如果您正在進行三到四次簡單選擇，那么您將不會以某種方式看到任何重大改進。

Answer 3

不要嘗試將自己的連接循環編寫為一堆選擇。 您的數據庫服務器有許多用於連接的聰明算法。 此外，您的數據庫服務器可以使用統計信息和估計的訪問成本來動態選擇連接算法。

數據庫服務器的連接算法通常比你編寫的任何東西都要好。 他們更了解物理I / O，緩存和什么不是。

這使您可以專注於您的問題域。

Answer 4

除了已經說過之外，要考慮的一件事是，選擇將通過網絡返回比連接可能更多的數據。 如果網絡連接已經成為瓶頸，這可能會使情況變得更糟，特別是如果經常這樣做的話。 也就是說，在任何性能情況下，最好的選擇是測試，測試和測試。

Answer 5

這完全取決於數據庫如何優化連接以及索引的使用。

我有一個緩慢而復雜的查詢，有很多連接。 然后我將其細分為2或3個不太復雜的查詢。 性能提升令人驚訝。

但最終，“它取決於”，你必須知道瓶頸在哪里。

Answer 6

如前所述，沒有背景就沒有正確的答案。

答案取決於（從我的頭腦）：

• 加入量
• 加入的類型
• 索引
• 您可以為要加入的任何單獨部分重復使用的數量
• 要處理的數據量
• 服務器設置
• 等等

Answer 7

如果您使用的是SQL Server（我不確定這是否可用於其他RDBMS），我建議您將執行計划與查詢結果捆綁在一起。 這將使您能夠准確查看查詢的執行方式以及導致任何瓶頸的原因。

在您了解SQL Server實際執行的操作之前，我不會猜測哪個查詢更好。

Answer 8

如果您的數據庫有大量數據....並且有多個連接，請使用索引以獲得更好的性能。

如果在這種情況下有左/右外連接，則使用多個選擇。

這一切都取決於你的數據庫大小，你的查詢，索引（也包括主鍵和外鍵）......你的問題是肯定/否的結論。