索引維護是資料庫日常維護中一項重要的任務，sql server的索引維護其實主要圍繞下面三個問題進行展開。
索引過多
索引不足
索引碎片率
本文同樣從這3個角度出發，介紹一些實用的日常維護方法和工具。
索引過多是指每個表上面的非聚集索引很多，并且有些非聚集索引很少用到。 過多的索引，會導緻增删資料的效率降低，資料庫體積變大，索引以及統計資訊的維護成本增加等負面影響，建議定期檢查類似的索引，每個表上面的索引最好不要超過10個。
通過下面兩個dmv，定期檢查索引使用率，通過使用率決定是否需要該索引。sys.dm_db_index_operational_stats這個函數可以給出某個索引上面的insert，update和delete的操作情況。sys.dm_db_index_usage_stats這個視圖可以給出通路索引的所有方法的操作概覽。
上述結果中，可以看到，countryregioncurrency和addresstype表中，有兩個索引，沒有使用過。 如果多次檢查，這兩個索引都還是沒有使用過的話，建議将其删除。
索引不足是指，要麼缺少索引，要麼有索引，但是沒有覆寫所需的列，查詢效果不好。 後者其實也可以歸納到索引不合适中。那麼我們來看下，如何才能找到缺失的索引。
sql server提供下面4個dmv以供查詢missing index的情況。sql server重新開機後，系統視圖中的内容就會更新，需要定期的将該資訊儲存下來。
下面語句，在每個庫上面執行下面的查詢，檢視推薦建立的索引，包括建立語句。不過在建立索引前，需要綜合考量表中已有的索引，是否有可以合并的情況。
建立index時，推薦按照下述順序進行。
将相等資料行列在最前
将不相等的資料行列在相等的資料行後
将include資料行列在create index語句的include子句中
若要決定相等資料行的順序，依據選擇性排列這些資料行，将選擇性最高的資料行排在最前
新增、删除和修改資料時，資料庫會自動維護索引。但時間長了之後，這些操作會造成資料不連續。這會對查找性能産生影響。
首先，觀察索引碎片的嚴重程度。
内部不連續（internal fragmentation）：資料頁中有很多空閑空間；
外部不連續（external fragmentation）：
硬碟中擺放的分頁或區不連續，也就是資料表或索引散落在多個範圍中，以及存放資料表或者索引的頁不是按照執行個體連續存放的。
邏輯資料順序和執行個體在硬碟中的順序不同。
1. 用dbcc showcontig觀察資料不連續
紅框中的參數反應外部不連續狀況。索引idcreditcard總共用了43頁，6個區，光标掃描區時轉換了5次，每個區平均7.2頁，掃描密度100%，邏輯掃描片段為0，區掃描碎片率33.33% （=讀取時跳過的區數/總共使用的區數）。
最後兩個參數avg. bytes free per page和avg. page density (full)則反應的是内部不連續的情況，平均每頁空閑位元組數越大，說明内部不連續越嚴重。
可以通過定義一個臨時表來觀察資料不連續情況。
檢視department表的索引不連續情況：
檢視資料庫中所有索引的碎片情況
3. 根據資料片段狀況來判斷是否要重組或者重建索引。
當索引碎片大于5%，小于等于30%時，建議reorganize該索引；當索引碎片率大于30%時，建議rebuild該索引。rebuild index比較耗性能，建議在非工作時間進行，同時，建議使用online 的方式來rebuild index，以減少鎖的申請量。
重組索引：
重建索引：
維護計劃重建索引