最佳SQL Server索引策略

恰當的索引能建立完全不同的效能。對於大多數的資料型別，SQL Server只支援兩種索引型別——聚簇索引和非聚簇索引。同時，SQL Server也支援全文索引和XML索引，但是它們只與特定資料型別相關。

　　為聚簇索引選擇恰當的欄位或欄位集是至關重要的。這是因為表的資料是根據聚簇索引欄位的值而物理地排序的。每個表上只能建立一個聚簇索引。非聚簇索引引用聚簇索引的鍵（資料值）來確定每個記錄的物理位置。

　　一般推薦在不會頻繁修改的、經常會被查詢的和有瘦資料型別的欄位上建立聚簇索引。在大多數情況下，在標識欄位上的聚簇索引是最佳的，因為標識值是最常被查詢的——每個記錄都有一個唯一的標識值——同時它們從不用更新，而且是使用SMALLINT、INT或BIGINT資料型別建立的。

　　然而，通常情況下是不會有一個表從來不被基於它的標識欄位查詢的。如果真有，我們就需要仔細考慮資料通常是如何檢索的，可能是通過指向另外一個表的外來鍵或者一個字元欄位。通常情況下，通過在最常用來檢索資料的欄位或欄位集上建立聚簇索引可以提高效能。

　　有些開發人員傾向於建立組合聚簇索引。它們都包括幾個欄位，是一個唯一標識每個記錄的組合。聽起來可能是一個很好的實踐方法，因為標識欄位沒有業務意義，而其它的欄位——如入職日期、部門名稱和車輛識別碼——一定可以被應用使用者快速理解。然而，對效能而言，我們必須避免使用組合聚簇索引。

　　再次，越瘦的索引，SQL Server可以越快地掃描或查詢。對於一個小的資料集，組合索引的效能相對更好些。但是，隨著使用者數增加，它將會出現更多的問題。

　　建立恰當的索引可以提高效能，我們也許會覺得工作已經完成了。但是，隨著表中資料的新增、修改和刪除，各個索引會出現碎片。碎片的程度越高，索引的效率就越低。因此，現在我們需要實現一個將索引中的碎片刪除的計劃，以便確保索引的有效性。

　　對於先前的SQL Server版本，從大索引（有數百萬行的表）中刪除碎片往往需要停機。幸運的是，SQL Server 2005支援線上索引重建。然而，記住，重建索引仍然需要佔用系統資源和資料庫的tempdb空間。可能的話，排程索引維護在活躍使用者最少的時間進行。

　　SQL Server資料庫架構師和管理員可以選擇多種方法來使他們的應用在一開始就表現良好。為了保證成功的資料庫效能，在設計階段作出很好的選擇非常重要。在這個版本的SQL Server INSIDER中，專家Baya Pavliashvili探討了如何作出可以優化效能的資料庫設計決定。設計一個資料庫包括合適的：

　　• 資料模型
　　• 資料型別
　　• 索引策略
　　• 程式碼模組
　　• 高可用選項

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-604318/，如需轉載，請註明出處，否則將追究法律責任。