5
我想知道查詢和視圖在性能方面有什麼區別。如果視圖成本高昂，除了查詢之外還有什麼可以提高性能？查詢與查看
Q
查詢與查看
A
回答
1
在簡單情況下，視圖和即席查詢在性能方面幾乎相同。如此一來，當您用視圖編程時，您應該將其視爲視圖定義的文本被剪切並粘貼到父查詢中。
HLGEM在他的回答中指出，某些版本的SQL Server允許您「索引」視圖 - 在這種情況下，SQL Server在後臺維護與表格背後相同的結構，製作索引視圖和表格在性能方面非常相似。
在SQL Server中，雖然通常可以相當寬鬆地嵌套視圖而不會遇到性能問題，但它可能使事情變得更難以理解和調試。
0
如果您指的是網絡性能，那麼從本地緩存工作（與使用ADO.Net DataSets一樣）將減少網絡流量 - 但可能會導致鎖定問題。只是一個想法。
1
如果他們執行完全相同的事情，則視圖在第一次執行時可能會稍微快一點，因爲數據庫服務器將爲其執行預編譯的執行計劃。取決於你的服務器。
Empasis的威力和咯...
+0
只是爲了從Oracle角度闡明，視圖在該平臺上沒有與它們相關聯的存儲執行計劃。視圖定義被合併到查詢中並且整個查詢被優化。 – 2008-12-04 19:36:27
0
視圖仍然是一個查詢，它只是抽象的某些部分，使您的查詢可以簡化（如果他們這樣做類似的東西），並最大限度地重用。
1
視圖促進了代碼重用，可以抽象出數據庫的複雜性，以提供更一致的「業務」數據模型。然而，它們幾乎沒有可調節性。您可能會發現自己處於需要提供聯合提示或其他低級別優化的位置，並且許多與之合作的DBA不喜歡將它們應用於視圖，因爲它們可能會在許多查詢中重用，意見是這些儘可能少地使用提示類型。我喜歡自己使用視圖。
2
在SQL Server中，我認爲視圖和查詢之間的性能差異可以忽略不計。我建議用來提高性能的方法是創建另一個表格來保存視圖的結果。您可以創建一個臨時表，其中保存新數據，然後可以以某個時間間隔運行存儲過程，以使用新信息填充工作表。觸發器可能對此有好處。根據您的應用要求，這種設計可能適用，也可能不適合。如果您正在處理接近實時的數據，這種方法將導致併發性問題...
另一個需要研究的問題是要確保您用於構建視圖的基表被編入索引正確，並且查詢本身已經過優化。最後，我相信在SQL Server企業中可以創建索引視圖，儘管我之前沒有使用它們。
+0
手動維護的「具體化查詢表」通常很難做到，而且在性能方面非常昂貴，無法精確維護，甚至忽略了磁盤空間的成本。 – 2008-11-27 17:28:01
1
對於計算機來說，查看勉強比寫出查詢花費更昂貴。一個視圖可以節省程序員/用戶很多時間，一次又一次地寫出相同的查詢，並且弄錯了，等等。如果視圖也用於強制對基礎表執行授權（訪問控制），則視圖也可能是訪問數據的唯一方法。
如果查詢不能很好地執行，則需要查看查詢是如何形成的以及這些表是否都具有適當的索引。如果您的系統需要精確的統計數據以使優化器表現良好，那麼您最近是否足夠更新了這些統計數據？
很久以前，我遇到了一個查詢生成器創建了一個查詢的系統，該查詢在單個FROM子句中列出了十七個表，其中包括與其自身表的幾個LEFT OUTER JOIN。事實上，更仔細的審查表明，其中一些「表」實際上是多表視圖，其中一些還涉及自外連接，並且它們本身涉及視圖的自外連接。說「可怕」是輕描淡寫。可以通過很多清理來提高查詢的性能 - 消除不必要的外連接，自連接等等。 （它實際上是SQL-92的明確加入符號的預先註明 - 我很久以前說過 - 所以外連接語法是DBMS特有的。）
3
我不能說所有的數據庫，但是在SQL Server中除非您有企業版本，否則無法爲視圖編制索引。未經索引的視圖在性能方面可能會比查詢更差，特別是如果您正在編寫針對它的查詢以在條件中添加一些查詢。索引視圖通常可以很好地執行。索引視圖也可以針對不同表中的多個字段，並且可以提高特定查詢的性能。 （它可能不會，在性能調整中，您必須始終針對您的特定情況進行測試。）
反對意見的一點是它們不允許運行時選擇哪裏標準。通常你最終會看到一個視圖和一個查詢。
視圖可以更容易維護（只需在聯接中添加新表，並且訪問財務報表的所有內容都可用），但它們對性能調整要困難得多。這部分是因爲它們往往是過度泛化的，因此比僅僅返回最小必需量的對應物慢。是的，正如喬納森所說，你可以非常容易地將報告的觀點融合在一起，這些混亂與同一張大桌子連接的次數比需要的次數多得多，而且速度很慢。
兩個地方，雖然意見閃耀，但： 確保複雜的關係總是正確描述。這是報告撰寫者傾向於贊成他們的原因之一。 限制對記錄子集的訪問
對於特殊查詢或存儲過程視圖副作用可以完成的查詢類型也有限制。例如，您不能使用if語句（或其他過程類型代碼，如循環），或者如上所述，您無法爲where條件提供運行時值。
一個地方的意見往往顯着較慢是當他們打電話給其他意見。底層視圖需要在某些數據庫中完全實現，因此您可能需要調用4,459,203條記錄來查看您最終感興趣的10個記錄。開始將其疊加多次，並且速度非常慢，速度非常快;調用意見的觀點只是一種不好的做法。
除非他們沒有。現在有這個問題。即時查詢的速度比轉換爲View的同一查詢快幾個數量級。所以總是三思。 – DanMan 2011-04-29 13:09:55
@丹曼除非你能解釋這種情況，否則這不是一個真正有用的評論。 – 2013-06-27 19:35:32