SQL Server索引的使用和最佳化

    在應用系統中,尤其在聯機交易處理系統中,對資料查詢及處理速度已成為衡量應用系統成敗的標準。而採用索引來加快資料處理速度也成為廣大資料庫使用者所接受的最佳化方法。

在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高效能的基礎，SQL Server採用基於代價的最佳化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高效能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個資料頁，如果有索引指向資料值，則查詢只需讀幾次磁碟就可以了。所以如果建立了合理的索引，最佳化器就能利用索引加速資料的查詢過程。但是，索引並不總是提高系統的效能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於最佳化那些效能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程式結合起來,才能產生最佳的最佳化方案。本文就SQL Server索引的效能問題進行了一些分析和實踐。

一、聚簇索引(clustered indexes)的使用

聚簇索引是一種對磁碟上實際資料重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指標指向資料頁面，所以使用聚簇索引尋找資料幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：

1、大多數表都應該有聚簇索引或使用分區來降低對錶尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的輸送量。

2、在聚簇索引下，資料在物理上按順序排在資料頁上，重複值也排在一起，因而在那些包含範圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有範圍中第一個索引值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜尋，避免了大範圍掃描，可以大大提高查詢速度。

3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖衝突。

4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，資料行必須移動到新的位置。

5、選擇聚簇索引應基於where子句和串連操作的類型。聚簇索引的侯選列是：

1、主鍵列,該列在where子句中使用並且插入是隨機的。

2、按範圍存取的列，如pri_order > 100 and pri_order < 200。

3、在group by或order by中使用的列。

4、不經常修改的列。

5、在串連操作中使用的列。

二、非聚簇索引(nonclustered indexes)的使用

SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的資料，而是對每一行儲存索引列值並用一個指標指向資料所在的頁面。換句話說非聚簇索引具有在索引結構和資料本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問資料的不同排序次序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：

1、索引需要使用多少空間。

2、合適的列是否穩定。

3、索引鍵是如何選擇的，掃描效果是否更佳。

4、是否有許多重複值。

對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該資料的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除資料的進程也會有類似的開銷，另外，刪除進程還必須把資料移到頁面上部，以保證資料的連續性。所以，建立非聚簇索引要非常謹慎。非聚簇索引常被用在以下情況:

1、某列常用於集合函數(如Sum,....)。

2、某列常用於join,order by,group by。

3、查尋出的資料不超過表中資料量的20%。

三、覆蓋索引(covering indexes)的使用

覆蓋索引是指那些索引項目中包含查尋所需要的全部資訊的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的資料,不需去訪問資料頁。如果非聚簇索引中包含結果資料,那麼它的查詢速度將快於聚簇索引。

但是由於覆蓋索引的索引項目比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低效能。