視圖性能增益仍然與現代RDBMS相關

毫無疑問，編寫SELECT * FROM viewCostumerAddress比SELECT c.id,c.name,a.id,a.fullAddress FROM customer c JOIN address a on a.id_costumer=c.id ORDER BY a.id,c.Priority更簡單直觀，但是當一羣人告訴你「視圖的性能更好」並且你的測試沒有顯示出獲得你的所作所爲？
我所進行的所有測試都使用相同的SQL Server 2014.該數據集包含大約2kk客戶端和2.5kk地址。在任何情況下，服務器的內存消耗都超過了60％。冷查詢測試總是伴隨着一個完整的服務重啓，以「強制清理」任何預編譯查詢和任何緩存信息。熱查詢的結果僅在每個查詢/查看命中200次後才被記錄，並儘可能多地過濾不同的值。所有測試均在專用的非虛擬服務器上進行1000次（裸機）。
然而，最終結果的熱點查詢變化小於1％（0.971％），冷查詢（0.0024％）變化小於0。面對這些結果，我開始懷疑在現代RDBMS世界和「對象 - 關係映射器」中，性能增益的舊聲明是否仍然有正當理由從視圖而不是直接查詢數據的數據？ PS：請儘量在您的答案中儘可能科學，提供測試方法（如果是案件）和/或科學論文，或者在舉報您目擊事件的情況下具體和徹底。視圖性能增益仍然與現代RDBMS相關

來源

2015-08-26 Leonardo

我從來沒有人向我提倡使用非物化視圖來提高性能。底層DDL的絕緣性肯定會改變，但絕不會影響性能。 –

唯一的性能優勢是隻需鍵入視圖名稱的開發人員。實際的視圖是相同的查詢，所以根本不會從性能角度獲益。如果牛羣中的任何人有任何文件來支持該聲明，我會感興趣。 –

如果您想討論查詢的性能（有或沒有視圖），請爲表和視圖提供查詢，其EXPLAIN和SHOW CREATE。 –

如果您有一個不是索引視圖的普通視圖，則沒有性能增益。這是因爲，當您從視圖中選擇時，SQL-Server運行T-SQL-Statement，就像它沒有視圖一樣。

這些都是我的一些想法的看法：

1意見是安全層

我個人不希望任何人去我的基表直接訪問。在視圖中，我可以根據調用者的權限篩選出行。直到SQL Server 2014，你不能用表來做到這一點。

2.視圖返回特定的一組列

的如果我不得不改變底層表的模式，我可以改變的方式的觀點，它返回相同的列之前。如果您不使用視圖並且用戶自己從基表中進行選擇，則查詢可能會失敗。

3.視圖是節省開發時間

您不必一遍又一遍地寫相同的T-SQL語句。那麼如果T-SQL語句中有錯誤呢？只需將它固定在一個地方，在視圖中。您可能不必更改應用程序或許多功能和存儲過程。

4.使用索引視圖，當你看到你的INNER JOIN的觀點是過於昂貴，有沒有更多的其他選項（如有用的索引或架構的變化），加快SELECT查詢

可以使用索引視圖來加速SELECT。但是，對於INSERT，UPDATE和DELETE，性能可能會下降，因爲視圖的索引也必須更新。

來源

2015-08-26 16:44:35 CPMunich

視圖性能增益仍然與現代RDBMS相關

回答

相關問題