我有一個要求是創建一個正在殺死處理器並花費很長時間運行的報告。SQL Server索引查看問題
我想我可以通過創建一個索引視圖來顯着提高速度，該視圖可以將所有這些數據保存在一個地方，使查詢/報告變得非常容易。這個觀點不僅僅用於報告，因爲我認爲它會在數據層的很多領域受益。
索引視圖可能會包含500萬以上的記錄，我似乎無法找到任何關於索引視圖不再推薦的指導。我認爲在SQL第一次啓動時，這個大小的索引視圖需要花費相當多的時間來構建，但是我希望在這之後維護它的代價將會很小。
有什麼樣的最佳實踐指南，何時使用索引視圖，何時不使用它們？在每次服務器重新啓動後，視圖會重建嗎？還是將它保存在磁盤的某個位置？
無論何時對索引中的任何列進行更新，與索引視圖關聯的索引都會更新。
大量的更新很可能會損害您的收益。如果它主要是讀取，那麼它會正常工作。
索引視圖的真正好處是當您的聚合實時計算過於昂貴時。
請參閱：Improving Performance with SQL Server 2008 Indexed Views：
索引視圖可以提高查詢以下列方式 性能：
- 聚合可以預先計算和存儲在索引查詢 過程中，儘量減少 昂貴的計算執行。
- 可以預先加入表格並存儲結果數據集。
- 可以存儲連接或聚合的組合。
查詢優化器會考慮索引只 觀點與平凡 費用查詢。這避免了 在查詢優化期間嘗試匹配各種索引視圖 成本 以上的情況，這比由 索引視圖使用率實現的節省更多。索引視圖是 很少用於查詢，成本爲 小於1。
應用從 落實索引視圖 受益包括：
- 決策支持工作負載。數據集市。
- 數據倉庫。
- 聯機分析處理（OLAP）存儲和來源。
- 數據挖掘工作負載。
從視圖的查詢類型和模式點 ，有益應用 可以表徵爲那些含有 ：
- 聯接和大表的聚合。
- 重複的查詢模式。
- 對相同或重疊的一組列進行重複聚合。
- 在相同的鍵上重複連接相同的表。
- 以上的組合。
我不知道任何關於索引視圖大小的指導。它實際上是一個獨立的表，每次更新它所依賴的基表時，它都會「自動」更新，所以我傾向於將它視爲一個單獨的表。
對於您在建立索引時的問題 - 它存儲在磁盤上，與其他索引相同，因此在服務器重新啓動期間不會重建（除了由於事務沒有進行而發生的任何修復在重啓之前完成）。
索引視圖（又名物化視圖）由SQL Server的每一個變化到基礎表（一個或多個）之後保持。不用說，你不應該有一個流量表的索引視圖。
對於您的問題，一個更好的解決辦法是運行查詢，並將其存儲在自己的表，如：
select * into CachedReport from YourView
這會給你的索引視圖的性能，同時可以當決定刷新它。例如，您可以通過每晚運行計劃作業的select into查詢來刷新它。
何時使用表或物化視圖沒有硬行數限制。 但是，作爲指導，避免在易失性表上進行物化視圖 - 負載可能會導致服務器死機。
首先，蒂莫西建議檢查基礎表上的索引，然後統計。您的查詢優化工具可能因缺少/過期統計信息而處於完整狀態。
如果這無助於性能檢查，那麼從視圖中確實需要哪些數據，因爲我的猜測是a）行數和b）行大小是將整個視圖加載到臨時表中並通過I/O爭用來運行它。
發佈緩慢的SQL和表defs – TFD 2010-02-09 11:31:19