SQL Server中有幾個可以讓你檢測
調整和優化SQL Server性能的工具
在本文中
我將說明如何用SQL Server的工具來優化數據庫索引的使用
本文還涉及到有關索引的一般性知識
關於索引的常識
影響到數據庫性能的最大因素就是索引
由於該問題的復雜性
我只可能簡單的談談這個問題
不過關於這方面的問題
目前有好幾本不錯的書籍可供你參閱
我在這裡只討論兩種SQL Server索引
即clustered索引和nonclustered索引
當考察建立什麼類型的索引時
你應當考慮數據類型和保存這些數據的column
同樣
你也必須考慮數據庫可能用到的查詢類型以及使用的最為頻繁的查詢類型
索引的類型
如果column保存了高度相關的數據
並且常常被順序訪問時
最好使用clustered索引
這是因為如果使用clustered索引
SQL Server會在物理上按升序（默認）或者降序重排數據列
這樣就可以迅速的找到被查詢的數據
同樣
在搜尋控制在一定范圍內的情況下
對這些column也最好使用clustered索引
這是因為由於物理上重排數據
每個表格上只有一個clustered索引
與上面情況相反
如果columns包含的數據相關性較差
你可以使用nonculstered索引
你可以在一個表格中使用高達
個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中選擇重新組織數據和數據頁
這將停止舊有索引並按特定的填充因子重建索引
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22246.html
