索引的類型

如果column保存了高度相關的數據，并且常常被順序訪問時，最好使用clustered索引，這是因為如果使用clustered索引，SQL Server會在物理上按升序（默認）或者降序重排數據列，這樣就可以迅速的找到被查詢的數據。同樣，在搜尋控制在一定范圍內的情況下，對這些column也最好使用clustered索引。這是因為由于物理上重排數據，每個表格上只有一個clustered索引。

與上面情況相反，如果columns包含的數據相關性較差，你可以使用nonculstered索引。你可以在一個表格中使用高達249個nonclustered索引——盡管我想象不出實際應用場合會用的上這么多索引。

當表格使用主關鍵字（primary keys），默認情況下SQL Server會自動對包含該關鍵字的column(s)建立一個獨有的cluster索引。很顯然，對這些column(s)建立獨有索引意味著主關鍵字的唯一性。當建立外關鍵字（foreign key）關系時，如果你打算頻繁使用它，那么在外關鍵字cloumn上建立nonclustered索引不失為一個好的方法。如果表格有clustered索引，那么它用一個鏈表來維護數據頁之間的關系。相反，如果表格沒有clustered索引，SQL Server將在一個堆棧中保存數據頁。

數據頁

當索引建立起來的時候，SQLServer就建立數據頁（datapage），數據頁是用以加速搜索的指針。當索引建立起來的時候，其對應的填充因子也即被設置。設置填充因子的目的是為了指示該索引中數據頁的百分比。隨著時間的推移，數據庫的更新會消耗掉已有的空閑空間，這就會導致頁被拆分。頁拆分的后果是降低了索引的性能，因而使用該索引的查詢會導致數據存儲的支離破碎。當建立一個索引時，該索引的填充因子即被設置好了，因此填充因子不能動態維護。

為了更新數據頁中的填充因子，我們可以停止舊有索引并重建索引，并重新設置填充因子（注意：這將影響到當前數據庫的運行，在重要場合請謹慎使用）。DBCC INDEXDEFRAG和DBCC DBREINDEX是清除clustered和nonculstered索引碎片的兩個命令。INDEXDEFRAG是一種在線操作（也就是說，它不會阻塞其它表格動作，如查詢），而DBREINDEX則在物理上重建索引。在絕大多數情況下，重建索引可以更好的消除碎片，但是這個優點是以阻塞當前發生在該索引所在表格上其它動作為代價換取來得。當出現較大的碎片索引時，INDEXDEFRAG會花上一段比較長的時間，這是因為該命令的運行是基于小的交互塊（transactional block）。

填充因子

當你執行上述措施中的任何一個，數據庫引擎可以更有效的返回編入索引的數據。關于填充因子（fillfactor）話題已經超出了本文的范疇，不過我還是提醒你需要注意那些打算使用填充因子建立索引的表格。

在執行查詢時，SQL Server動態選擇使用哪個索引。為此，SQL Server根據每個索引上分布在該關鍵字上的統計量來決定使用哪個索引。值得注意的是，經過日常的數據庫活動（如插入、刪除和更新表格），SQL Server用到的這些統計量可能已經“過期”了，需要更新。你可以通過執行DBCC SHOWCONTIG來查看統計量的狀態。當你認為統計量已經“過期”時，你可以執行該表格的UPDATE STATISTICS命令，這樣SQL Server就刷新了關于該索引的信息了。

建立數據庫維護計劃

SQL Server提供了一種簡化并自動維護數據庫的工具。這個稱之為數據庫維護計劃向導（Database Maintenance Plan Wizard ，DMPW）的工具也包括了對索引的優化。如果你運行這個向導，你會看到關于數據庫中關于索引的統計量，這些統計量作為日志工作并定時更新，這樣就減輕了手工重建索引所帶來的工作量。如果你不想自動定期刷新索引統計量，你還可以在DMPW中選擇重新組織數據和數據頁，這將停止舊有索引并按特定的填充因子重建索引。