如何開始索引新的數據倉庫
我正在建構一個數據倉庫（SQL Server 2012，Kimball Dimensional modeling，750GB），它將向報告（SSRS）、多維數據集（SSAS）和各種數據饋送提供數據。
我打算使用索引調整工具（可能是sp_BlitzIndex），但我該如何開始呢？我是否從沒有索引開始，然後讓 sp_BlitzIndex 告訴我一段時間後要使用哪些索引？還是**從明顯的索引開始，**然後使用 sp_BlitzIndex 建構？
我計劃在每個主鍵上添加一個聚集索引，在每個外鍵上添加一個非聚集索引——然後讓 sp_BlitzIndex 建議不太明顯的選擇。但也許我應該把它全部交給 sp_BlitzIndex。
您從主鍵上的聚集索引開始的計劃是一個很好的開始。
理想情況下，您的聚群索引（開始）應該是
INTEGER IDENTITYDW 的代理鍵：
- 保持聚集索引盡可能窄，
- 這樣維度表和事實表就不是堆了。
當且僅當您期望一個表超過 2,147,483,647 行（最大 INT 值）時，使用
BIGINT IDENTITY代替INT. （請參閱數值數據類型）。仔細考慮每個外鍵上的非聚集索引。將 NCI 放在每個外鍵上可能沒有必要，而且可能弊大於利。相反，只專注於在查詢中的 JOIN 或 WHERE 子句中使用它們的外鍵上創建非聚集索引。但是，不要只為每個 FK 創建一個非聚集索引——如果一個查詢在連接中使用多個 FK，請考慮創建一個 NCI 來支持這些連接。使用索引鍵列的順序來查看哪個效果最好。測試測試測試。
編輯 9/26/2016 這是 Kendra Little 討論外鍵索引的部落格文章： http ://www.littlekendra.com/2016/09/22/indexing-foreign-keys-guidelines/
堆對 SELECT / UPDATE / DELETE 性能（即 SSRS 和 SSAS 查詢）不利，尤其是對於查詢中的任何類型的 JOIN 或 WHERE 子句，因為堆上的所有查詢都是表掃描——沒有堆搜尋之類的東西。碎片通常是 HEAP 表的問題。
堆非常適合 INSERT 性能。眾所周知，堆對於插入新數據是最快的，因為如果有索引，則不會對 SQL Server 需要管理的數據進行索引更改（即更新索引的 b 樹）或排序。這對於 STAGING 表最有用。（請參閱堆表的有效使用場景是什麼）。在插入新數據時，HEAPS 優於 CLUSTERED INDEXES 的程度會有所不同。
編輯：2016 年 9 月 7 日這是 Daniel Hutmacher 的部落格文章，討論了堆的其他案例： https ://sqlsunday.com/2016/09/01/compelling-case-for-heaps/
請注意，聚集索引（和非聚集索引）會降低（假設的）每日夜間負載的性能，因為任何數據更改（INSERT、UPDATE、DELETES、MERGE）都會導致使用這些列的索引具有更改的數據（I’ ll 將 INSERTed、UPDATEd、DELETEd、MERGEd 組合為“已更改”數據）也將被更新，這會導致 I/O 寫入索引。這可能對性能造成很小的影響；這可能會對性能造成很大影響——這取決於表的大小和正在更改的數據量 (I/U/D/M) 以及其他因素。一個“小”維度表可能會很好地為 ETL 保留聚集索引和非聚集索引。“大”維度表可能會受益於禁用/重新建構方法。測試測試測試。).
一種方法（不一定是推薦，而是一種選擇）來對抗具有現有索引的（大）表的數據更改的性能降低是：
- 在載入數據之前禁用或刪除表的索引作為 SSIS ETL 作業的一部分，以優化 INSERT 性能，
- 然後在數據載入完成後重建或重新創建索引。
如果您嘗試這條路線，請測試並跟踪性能，以確保此方法確實比將數據載入到帶有索引的表中更快——它可能不會更快。測試測試測試。
在性能調整查詢時，
SET STATISTICS IO, TIME ON;在您的 SELECT 查詢之前進行測量。專注於使用非聚集索引減少“邏輯讀取”。記錄和跟踪索引之前和索引之後的邏輯讀取；保留歷史。如果你成功了，你可以向你的團隊和/或老闆展示這些數字。您的數據倉庫將提供 SSRS 報告和 SSAS 多維數據集處理執行。創建支持/調整這些查詢的非聚集索引（也許 SSRS 和 SSAS 使用的查詢是視圖或儲存過程？）。換句話說，調整您的 SSRS/SSAS 查詢（通過非聚集索引）。您需要讓您的 SSRS 報告視圖或過程查詢程式碼在計劃記憶體的一段時間內（例如，穩定執行 1 週）保持靜態/穩定（即沒有程式碼更改），然後繼續進行調整。您可以更早地做到這一點，但您可能不會得到相同的結果。
為了優化 SSAS，在 SSAS 多維數據集處理執行期間使用 Profiler（或擴展事件，如果您願意）來擷取多維數據集在從 DW 提取數據時使用的 SELECT 查詢——這可能不是您所期望的。這些是您為改進 SSAS 多維數據集處理時間而調整的查詢。完成後不要忘記關閉分析器，因為它確實會增加一些成本。
索引調整 DW 的好處是，您還可以同時調整 SSRS 報告和 SSAS 多維數據集處理執行。
索引性能調整是一種持續的實踐；你永遠不會完成。如果出現以下情況，您可能需要更改索引策略：
- 新表被創建/加入
- 視圖/儲存過程的新 where 子句或新聯接
- 新列被添加到現有表中
- 數據更改（即現在比您第一次調整索引時多了 100 萬、1000 萬或 1 億行）
索引性能調整可能具有挑戰性和技巧性，但當您獲得巨大的性能勝利時會非常有回報。我鼓勵您搜尋專門討論索引策略的免費網路研討會。了解不同類型的非聚集索引（即“覆蓋”索引、過濾索引、列儲存索引等）以及它們如何以及何時有用，以及何時它們可能弊大於利。
當您準備好超越免費網路研討會時，請考慮尋找要購買的書籍和/或付費培訓以進一步提高您的索引技能——也許您的雇主會為培訓和/或書籍付費。由於您提到了 Brent Ozar 團隊的 sp_BlitzIndex，Kendra Little 完成了很棒的面對面付費課程（我參加過）並錄製了有關索引性能調整的網路研討會。還有很多其他優秀的 MVP 和優秀的 SQL 專業人士也提供索引培訓。
祝你好運，我希望這是有幫助和有見地的。