假設我有一個並不真正「很好」的SQL查詢。性能:查看或查詢
SQL查詢有很長的條件內部連接,最後是一個簡單的「where」語句。
現在假設我創建了一個與該SQL查詢相對應的視圖,除了最後的「where」語句。因此,我不使用這個長查詢,而是使用視圖並簡單地添加「where」語句。
我的問題是以下幾點: 哪一個會有最好的表現?
我不確定「查看」選項是否符合兩個sql語句,而不是第一個選項的一個sql語句。或者在執行查詢之前,「查看」查詢在更簡單的查詢中被「粘貼」並且是「相同的」。
假設我有一個並不真正「很好」的SQL查詢。性能:查看或查詢
SQL查詢有很長的條件內部連接,最後是一個簡單的「where」語句。
現在假設我創建了一個與該SQL查詢相對應的視圖,除了最後的「where」語句。因此,我不使用這個長查詢,而是使用視圖並簡單地添加「where」語句。
我的問題是以下幾點: 哪一個會有最好的表現?
我不確定「查看」選項是否符合兩個sql語句,而不是第一個選項的一個sql語句。或者在執行查詢之前,「查看」查詢在更簡單的查詢中被「粘貼」並且是「相同的」。
沒有區別。該視圖僅使用與查詢相同的查詢。
爲了不同,它需要將其存儲在視圖表視圖中,它們只是從外部看起來很容易的查詢。
假設您正在使用的DBMS具有基於成本的查詢優化器,那麼當部分查詢轉換爲視圖時,您可能無法獲得更好的性能。您可以通過比較兩個版本的查詢的估計成本來確認這與您的數據庫的查詢說明工具。
我推薦使用查詢解釋實用程序來確定查詢的確切位置,因爲查詢的痛點通常是意料之外的位置。看起來,所有這些連接都會減慢速度,但它們可能會利用索引來最大限度地減少連接行所需的I/O和CPU週期。很多時候,由於在WHERE或ON子句中引用了無索引的列,所以查詢陷入了沉寂。
爲什麼downvote?這似乎是個好問題。 –
我沒有降低你的... ...意見有許多優點...但「表現」(至少在這種情況下)當然不是其中之一;) – paulsm4