2012-06-16 92 views
3

假設我有一個並不真正「很好」的SQL查詢。性能:查看或查詢

SQL查詢有很長的條件內部連接,最後是一個簡單的「where」語句。

現在假設我創建了一個與該SQL查詢相對應的視圖,除了最後的「where」語句。因此,我不使用這個長查詢,而是使用視圖並簡單地添加「where」語句。

我的問題是以下幾點: 哪一個會有最好的表現?

我不確定「查看」選項是否符合兩個sql語句,而不是第一個選項的一個sql語句。或者在執行查詢之前,「查看」查詢在更簡單的查詢中被「粘貼」並且是「相同的」。

+0

爲什麼downvote?這似乎是個好問題。 –

+0

我沒有降低你的... ...意見有許多優點...但「表現」(至少在這種情況下)當然不是其中之一;) – paulsm4

回答

1

沒有區別。該視圖僅使用與查詢相同的查詢。

爲了不同,它需要將其存儲在視圖表視圖中,它們只是從外部看起來很容易的查詢。

1

假設您正在使用的DBMS具有基於成本的查詢優化器,那麼當部分查詢轉換爲視圖時,您可能無法獲得更好的性能。您可以通過比較兩個版本的查詢的估計成本來確認這與您的數據庫的查詢說明工具。

我推薦使用查詢解釋實用程序來確定查詢的確切位置,因爲查詢的痛點通常是意料之外的位置。看起來,所有這些連接都會減慢速度,但它們可能會利用索引來最大限度地減少連接行所需的I/O和CPU週期。很多時候,由於在WHERE或ON子句中引用了無索引的列,所以查詢陷入了沉寂。

+0

也許我解釋了它錯了,但我期待那使用視圖會給我更糟糕的表現,因爲我猜想這意味着兩個查詢,第一個得到視圖表,第二個使用該表過濾「where」。感謝您的回覆 – pritzo

+0

引用視圖的語句仍將作爲優化程序的一條語句處理。在內部,優化器只是抓取視圖的SQL並將其放到引用視圖的查詢中。引用視圖不太可能會影響優化器解析查詢所需的時間,解決表引用並提出它認爲是採用表的索引,基數和數據的最佳訪問計劃分配到帳戶。 –

+0

優化程序的類型與視圖的執行效果是否優於即席查詢沒有關係。 – Andomar