SQL Server 索引優化
——無用索引和索引缺失（三）
SQL Server 索引優化——無用索引和索引缺失中，我們根據動態視圖sys.dm_db_index_usage_stats 探測無用索引；SQL Server 索引優化——無用索引和索引缺失（二）中使用動態視圖sys.dm_db_missing_index_details、sys.dm_db_missing_index_groups、sys.dm_db_missing_index_group_stats 發現缺失索引。本文將根據“數據庫引擎優化顧問”（DTA）來發現無用或缺失的索引。
要使用“數據庫引擎優化顧問”，首先需要對數據庫負載進行監控，爲數據庫負載分析準備數據。從SSMS的工具中，打開SQL Server Profile，輸入安全連接方式。在常規的標籤下，模板選擇“Standard（默認值）”，事件選擇標籤下，選擇事件Stored Procedures→RPC：Completed；TSQL→SQL：BatchCompleted，SQL：BatchStarting，點擊運行。如下圖所示：
監控一段時間後，停止運行，將跟蹤文件保存爲trace.trc
在SSMS的工具下，打開“數據庫引擎優化顧問”，建立安全連接，如下圖。在“工作負荷”下選擇跟蹤文件所在的路徑，選擇“工作負荷分析的數據庫”，這裏我選擇的tempdb；最後選擇需要優化的數據庫和表。
在優化選項中，“限定優化時間”可以不選，或者自己設定結束時間；“在數據庫中使用的物理設計結構（PDS）”，選擇“索引和索引視圖(D）”；“使用的分區策略”選擇“對齊分區（A）”；在數據庫中保留的物理設計結構（PDS），我選擇了“保留對齊分區（R）”，設定如下：
點擊開始運行後，獲得如下建議
通過測試可以瞭解到，最終的索引或分區建議，與Profile追蹤的時間長短、時間段有關。如果工作負載不代表該數據庫的典型工作負載，並且缺少重要的查詢，那麼索引建議也將是不完整的、不準確的或完全錯誤的。使用該方法的要求是：
-
在不影響生產環境的性能的情況下，儘可能的延長跟蹤時間，蒐集較多的事件；
-
將需要優化的數據庫備份，還原到非生產環境服務器，進行分析（因爲保證1的情況下，數據量會非常大，在原生產環境進行分析，會消耗大量的生產環境的資源CPU、IO，降低生產環境的性能，影響業務）
比較動態視圖和數據庫引擎優化顧問，兩者的共同缺點都是可能因蒐集的信息不全，導致建議不準確， 所以無論使用動態視圖，還是使用數據庫引擎優化顧問，其建議都需要審慎使用。
最後再重申一遍，雖然這些特性在確定可能對數據庫有益的索引時非常有用，但它們也可能是一把雙刃劍，在錯誤使用時弊大於利。盲目地實現這些特性的建議幾乎總是會導致數據庫中的索引重複或重疊，以及索引太多而不是太少。
如果喜歡，可以掃碼關注SQL Server 公衆號，將有更多精彩內容分享：
