轉載自《http://www.cnblogs.com/newpanderking/p/3781043.html》

1、首先要明白無名無實莫要用索引：因為資料中的記錄很多，為了方便我們查詢，提高查詢的效率；

3、索引是優缺點：   首先明白為什麼索引會增加速度，DB在執行一條Sql語句的時候，預設的方式是根據搜尋條件進行全表掃描，遇到匹配條件的就加入搜尋結果集合。如果我們對某一欄位增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍歷匹配的行數，所以能明顯增加查詢的速度。那麼在任何時候都應該加索引麼？這裡有幾個反例：1、如果每次都需要取到所有表記錄，無論如何都必須進行全表掃描了，那麼是否加索引也沒有意義了。2、對非唯一的欄位，例如“性別”這種大量重複值的欄位，增加索引也沒有什麼意義。3、對於記錄比較少的表，增加索引不會帶來速度的優化反而浪費了儲存空間，因為索引是需要儲存空間的，而且有個致命缺點是對於update/insert/delete的每次執行，欄位的索引都必須重新計算更新。所以並不是任何情況下都改建立索引的

一、為什麼要建立索引呢（優點）？
這是因為，建立索引可以大大提高系統的效能。
第一，   通過建立唯一性索引，可以保證資料庫表中每一行資料的唯一性。
第二，   可以大大加快資料的檢索速度，這也是建立索引的最主要的原因。
第三，   可以加速表和表之間的連線，特別是在實現資料的參考完整性方面特別有意義。
第四，   在使用分組和排序子句進行資料檢索時，同樣可以顯著減少查詢中分組和排序的時間。
第五，   通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的效能。

二、建立方向索引的不利因素（缺點）
也許會有人要問：增加索引有如此多的優點，為什麼不對錶中的每一個列建立一個索引呢？這種想法固然有其合理性，然而也有其片面性。雖然，索引有許多優點，但是，為表中的每一個列都增加索引，是非常不明智的。這是因為，增加索引也有許多不利的一個方面。

第一，   建立索引和維護索引要耗費時間，這種時間隨著資料量的增加而增加。
第二，   索引需要佔物理空間，除了資料表佔資料空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。
第三，   當對錶中的資料進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了資料的維護速度。 

三、建立方向索引的準則
索引是建立在資料庫表中的某些列的上面。因此，在建立索引的時候，應該仔細考慮在哪些列上可以建立索引，在哪些列上不能建立索引。
一般來說，應該在這些列上建立索引。
第一，   在經常需要搜尋的列上，可以加快搜索的速度；
第二，   在作為主鍵的列上，強制該列的唯一性和組織表中資料的排列結構；
第三，   在經常用在連線的列上，這些列主要是一些外來鍵，可以加快連線的速度；
第四，   在經常需要根據範圍進行搜尋的列上建立索引，因為索引已經排序，其指定的範圍是連續的；
第五，   在經常需要排序的列上建立索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；
第六，   在經常使用在WHERE子句中的列上面建立索引，加快條件的判斷速度。 

同樣，對於有些列不應該建立索引。一般來說，不應該建立索引的的這些列具有下列特點：
第一，             對於那些在查詢中很少使用或者參考的列不應該建立索引。這是因為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。
第二，             對於那些只有很少資料值的列也不應該增加索引。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的資料行佔了表中資料行的很大比例，即需要在表中搜索的資料行的比例很大。增加索引，並不能明顯加快檢索速度。
第三，             對於那些定義為text, image和bit資料型別的列不應該增加索引。這是因為，這些列的資料量要麼相當大，要麼取值很少。
第 四，             當修改效能遠遠大於檢索效能時，不應該建立索引。這是因為，修改效能和檢索效能是互相矛盾的。當增加索引時，會提高檢索效能，但是會降低修改效能。當減少 索引時，會提高修改效能，降低檢索效能。因此，當修改效能遠遠大於檢索效能時，不應該建立索引。 
四、建立索引的方法 
建立索引有多種方法，這些方法包括直接建立索引的方法和間接建立索引的方法。
第一，   直接建立索引，例如使用CREATE INDEX語句或者使用建立索引向導。
第二，   間接建立索引，例如在表中定義主鍵約束或者唯一性鍵約束時，同時也建立了索引。
雖然，這兩種方法都可以建立索引，但是，它們建立索引的具體內容是有區別的。 
使 用CREATE INDEX語句或者使用建立索引向導來建立索引，這是最基本的索引建立方式，並且這種方法最具有柔性，可以定製創建出符合自己需要的索引。在使用這種方式 建立索引時，可以使用許多選項，例如指定資料頁的充滿度、進行排序、整理統計資訊等，這樣可以優化索引。使用這種方法，可以指定索引的型別、唯一性和複合 性，也就是說，既可以建立聚簇索引，也可以建立非聚簇索引，既可以在一個列上建立索引，也可以在兩個或者兩個以上的列上建立索引。 
通過定義主 鍵約束或者唯一性鍵約束，也可以間接建立索引。主鍵約束是一種保持資料完整性的邏輯，它限制表中的記錄有相同的主鍵記錄。在建立主鍵約束時，系統自動建立 了一個唯一性的聚簇索引。雖然，在邏輯上，主鍵約束是一種重要的結構，但是，在物理結構上，與主鍵約束相對應的結構是唯一性的聚簇索引。換句話說，在物理 實現上，不存在主鍵約束，而只存在唯一性的聚簇索引。同樣，在建立唯一性鍵約束時，也同時建立了索引，這種索引則是唯一性的非聚簇索引。因此，當使用約束 建立索引時，索引的型別和特徵基本上都已經確定了，由使用者定製的餘地比較小。 
當在表上定義主鍵或者唯一性鍵約束時，如果表中已經有了使用 CREATE INDEX語句建立的標準索引時，那麼主鍵約束或者唯一性鍵約束建立的索引覆蓋以前建立的標準索引。也就是說，主鍵約束或者唯一性鍵約束建立的索引的優先 級高於使用CREATE INDEX語句建立的索引。 
五、索引的特徵 
    索引有兩個特徵，即唯一性索引和複合索引。 
唯 一性索引保證在索引列中的全部資料是唯一的，不會包含冗餘資料。如果表中已經有一個主鍵約束或者唯一性鍵約束，那麼當建立表或者修改表時，SQL Server自動建立一個唯一性索引。然而，如果必須保證唯一性，那麼應該建立主鍵約束或者唯一性鍵約束，而不是建立一個唯一性索引。當建立唯一性索引 時，應該認真考慮這些規則：當在表中建立主鍵約束或者唯一性鍵約束時，SQL Server自動建立一個唯一性索引；如果表中已經包含有資料，那麼當建立索引時，SQL Server檢查表中已有資料的冗餘性；每當使用插入語句插入資料或者使用修改語句修改資料時，SQL Server檢查資料的冗餘性：如果有冗餘值，那麼SQL Server取消該語句的執行，並且返回一個錯誤訊息；確保表中的每一行資料都有一個唯一值，這樣可以確保每一個實體都可以唯一確認；只能在可以保證實體 完整性的列上建立唯一性索引，例如，不能在人事表中的姓名列上建立唯一性索引，因為人們可以有相同的姓名。 
複合索引就是一個索引建立在兩個列 或者多個列上。在搜尋時，當兩個或者多個列作為一個關鍵值時，最好在這些列上建立複合索引。當建立複合索引時，應該考慮這些規則：最多可以把16個列合併 成一個單獨的複合索引，構成複合索引的列的總長度不能超過900位元組，也就是說複合列的長度不能太長；在複合索引中，所有的列必須來自同一個表中，不能跨 表建立複合列；在複合索引中，列的排列順序是非常重要的，因此要認真排列列的順序，原則上，應該首先定義最唯一的列，例如在（COL1，COL2）上的索 引與在（COL2，COL1）上的索引是不相同的，因為兩個索引的列的順序不同；為了使查詢優化器使用複合索引，查詢語句中的WHERE子句必須參考複合 索引中第一個列；當表中有多個關鍵列時，複合索引是非常有用的；使用複合索引可以提高查詢效能，減少在一個表中所建立的索引數量。 
六、索引的型別 
根據索引的順序與資料表的物理順序是否相同，可以把索引分成兩種型別。一種是資料表的物理順序與索引順序相同的聚簇索引，另一種是資料表的物理順序與索引順序不相同的非聚簇索引。 
七、聚簇索引的體系結構 
索 引的結構類似於樹狀結構，樹的頂部稱為葉級，樹的其它部分稱為非葉級，樹的根部在非葉級中。同樣，在聚簇索引中，聚簇索引的葉級和非葉級構成了一個樹狀結 構，索引的最低階是葉級。在聚簇索引中，表中的資料所在的資料頁是葉級，在葉級之上的索引頁是非葉級，索引資料所在的索引頁是非葉級。在聚簇索引中，資料 值的順序總是按照升序排列。 
應該在表中經常搜尋的列或者按照順序訪問的列上建立聚簇索引。當建立聚簇索引時，應該考慮這些因素：每一個表只能 有一個聚簇索引，因為表中資料的物理順序只能有一個；表中行的物理順序和索引中行的物理順序是相同的，在建立任何非聚簇索引之前建立聚簇索引，這是因為聚 簇索引改變了表中行的物理順序，資料行按照一定的順序排列，並且自動維護這個順序；關鍵值的唯一性要麼使用UNIQUE關鍵字明確維護，要麼由一個內部的 唯一識別符號明確維護，這些唯一性識別符號是系統自己使用的，使用者不能訪問；聚簇索引的平均大小大約是資料表的百分之五，但是，實際的聚簇索引的大小常常根據 索引列的大小變化而變化；在索引的建立過程中，SQL Server臨時使用當前資料庫的磁碟空間，當建立聚簇索引時，需要1.2倍的表空間的大小，因此，一定要保證有足夠的空間來建立聚簇索引。 
當 系統訪問表中的資料時，首先確定在相應的列上是否存在有索引和該索引是否對要檢索的資料有意義。如果索引存在並且該索引非常有意義，那麼系統使用該索引訪 問表中的記錄。系統從索引開始瀏覽到資料，索引瀏覽則從樹狀索引的根部開始。從根部開始，搜尋值與每一個關鍵值相比較，確定搜尋值是否大於或者等於關鍵 值。這一步重複進行，直到碰上一個比搜尋值大的關鍵值，或者該搜尋值大於或者等於索引頁上所有的關鍵值為止。 
八、非聚簇索引的體系結構 
非聚簇索引的結構也是樹狀結構，與聚簇索引的結構非常類似，但是也有明顯的不同。 
在非聚簇索引中，葉級僅包含關鍵值，而沒有包含資料行。非聚簇索引表示行的邏輯順序。    非聚簇索引有兩種體系結構：一種體系結構是在沒有聚簇索引的表上建立非聚簇索引，另一種體系結構是在有聚簇索引的表上建立非聚簇索引。 
如 果一個數據表中沒有聚簇索引，那麼這個資料表也稱為資料堆。當非聚簇索引在資料堆的頂部建立時，系統使用索引頁中的行識別符號指向資料頁中的記錄。行識別符號 儲存了資料所在位置的資訊。資料堆是通過使用索引分配圖（IAM）頁來維護的。IAM頁包含了資料堆所在簇的儲存資訊。在系統表sysindexes中， 有一個指標指向了與資料堆相關的第一個IAM頁。系統使用IAM頁在資料堆中瀏覽和尋找可以插入新的記錄行的空間。這些資料頁和在這些資料頁中的記錄沒有 任何的順序並且也沒有連結在一起。在這些資料頁之間的唯一的連線是IAM中記錄的順序。當在資料堆上建立了非聚簇索引時，葉級中包含了指向資料頁的行標識 符。行識別符號指定記錄行的邏輯順序，由檔案ID、頁號和行ID組成。這些行的識別符號維持唯一性。非聚簇索引的葉級頁的順序不同於表中資料的物理順序。這些 關鍵值在葉級中以升序維持。 
當非聚簇索引建立在有聚簇索引的表上的時候，系統使用索引頁中的指向聚簇索引的聚簇鍵。聚簇鍵儲存了資料的位置信 息。如果某一個表有聚簇索引，那麼非聚簇索引的葉級包含了對映到聚簇鍵的聚簇鍵值，而不是對映到物理的行識別符號。當系統訪問有非聚簇索引的表中資料時，並 且這種非聚簇索引建立在聚簇索引上，那麼它首先從非聚簇索引來找到指向聚簇索引的指標，然後通過使用聚簇索引來找到資料。 
    當需要以多種方式檢索資料時，非聚簇索引是非常有用的。當建立非聚簇索引時，要考慮這些情況：在預設情況下，所建立的索引是非聚簇索引；在每一個表上面，可以建立不多於249個非聚簇索引，而聚簇索引最多隻能有一個。
系統如何訪問表中的資料 
一 般地，系統訪問資料庫中的資料，可以使用兩種方法：表掃描和索引查詢。第一種方法是表掃描，就是指系統將指標放置在該表的表頭資料所在的資料頁上，然後按 照資料頁的排列順序，一頁一頁地從前向後掃描該表資料所佔有的全部資料頁，直至掃描完表中的全部記錄。在掃描時，如果找到符合查詢條件的記錄，那麼就將這 條記錄挑選出來。最後，將全部挑選出來符合查詢語句條件的記錄顯示出來。第二種方法是使用索引查詢。索引是一種樹狀結構，其中儲存了關鍵字和指向包含關鍵 字所在記錄的資料頁的指標。當使用索引查詢時，系統沿著索引的樹狀結構，根據索引中關鍵字和指標，找到符合查詢條件的的記錄。最後，將全部查詢到的符合查 詢語句條件的記錄顯示出來。 
    在SQL Server中，當訪問資料庫中的資料時，由SQL Server確定該表中是否有索引存在。如果沒有索引，那麼SQL Server使用表掃描的方法訪問資料庫中的資料。查詢處理器根據分佈的統計資訊生成該查詢語句的優化執行規劃，以提高訪問資料的效率為目標，確定是使用 表掃描還是使用索引。 
九、索引的選項 
    在建立索引時，可以指定一些選項，通過使用這些選項，可以優化索引的效能。這些選項包括FILLFACTOR選項、PAD_INDEX選項和SORTED_DATA_REORG選項。 
使 用FILLFACTOR選項，可以優化插入語句和修改語句的效能。當某個索引頁變滿時，SQL Server必須花費時間分解該頁，以便為新的記錄行騰出空間。使用FILLFACTOR選項，就是在葉級索引頁上分配一定百分比的自由空間，以便減少頁 的分解時間。當在有資料的表中建立索引時，可以使用FILLFACTOR選項指定每一個葉級索引節點的填充的百分比。預設值是0，該數值等價於100。在 建立索引的時候，內部索引節點總是留有了一定的空間，這個空間足夠容納一個或者兩個表中的記錄。在沒有資料的表中，當建立索引的時候，不要使用該選項，因 為這時該選項是沒有實際意義的。另外，該選項的數值在建立時指定以後，不能動態地得到維護，因此，只應該在有資料的表中建立索引時才使用。 
PAD_INDEX 選項將FILLFACTOR選項的數值同樣也用於內部的索引節點，使內部的索引節點的填充度與葉級索引的節點中的填充度相同。如果沒有指定 FILLFACTOR選項，那麼單獨指定PAD_INDEX選項是沒有實際意義的，這是因為PAD_INDEX選項的取值是由FILLFACTOR選項的 取值確定的。 
當建立聚簇索引時，SORTED_DATA_REORG選項清除排序，因此可以減少建立聚簇索引所需要的時間。當在一個已經變成 碎塊的表上建立或者重建聚簇索引時，使用SORTED_DATA_REORG選項可以壓縮資料頁。當重新需要在索引上應用填充度時，也使用該選項。當使用 SORTED_DATA_REORG選項時，應該考慮這些因素：SQL Server確認每一個關鍵值是否比前一個關鍵值高，如果都不高，那麼不能建立索引；SQL Server要求1.2倍的表空間來物理地重新組織資料；使用SORTED_DATA_REORG選項，通過清除排序程序而加快索引建立程序；從表中物理 地拷貝資料；當某一個行被刪除時，其所佔的空間可以重新利用；建立全部非聚簇索引；如果希望把葉級頁填充到一定的百分比，可以同時使用 FILLFACTOR選項和SORTED_DATA_REORG選項。 
十、索引的維護 
為了維護系統性能，索引在建立之後，由於頻繁地對資料進行增加、刪除、修改等操作使得索引頁發生碎塊，因此，必須對索引進行維護。 
使 用DBCC SHOWCONTIG語句，可以顯示錶的資料和索引的碎塊資訊。當執行DBCC SHOWCONTIG語句時，SQL Server瀏覽葉級上的整個索引頁，來確定表或者指定的索引是否嚴重碎塊。DBCC SHOWCONTIG語句還能確定資料頁和索引頁是否已經滿了。當對錶進行大量的修改或者增加大量的資料之後，或者表的查詢非常慢時，應該在這些表上執行 DBCC SHOWCONTIG語句。當執行DBCC SHOWCONTIG語句時，應該考慮這些因素：當執行DBCC SHOWCONTIG語句時，SQL Server要求指定表的ID號或者索引的ID號，表的ID號或者索引的ID號可以從系統表sysindexes中得到；應該確定多長時間使用一次 DBCC SHOWCONTIG語句，這個時間長度要根據表的活動情況來定，每天、每週或者每月都可以。 
使用DBCC DBREINDEX語句重建表的一個或者多個索引。當希望重建索引和當表上有主鍵約束或者唯一性鍵約束時，執行DBCC DBREINDEX語句。除此之外，執行DBCC DBREINDEX語句還可以重新組織葉級索引頁的儲存空間、刪除碎塊和重新計算索引統計。當使用執行DBCC DBREINDEX語句時，應該考慮這些因素：根據指定的填充度，系統重新填充每一個葉級頁；使用DBCC DBREINDEX語句重建主鍵約束或者唯一性鍵約束的索引；使用SORTED_DATA_REORG選項可以更快地建立聚簇索引，如果沒有排列關鍵值， 那麼不能使用DBCC DBREINDEX語句；DBCC DBREINDEX語句不支援系統表。另外，還可以使用資料庫維護規劃嚮導自動地進行重建索引的程序。 
統計資訊是儲存在SQL Server中的列資料的樣本。這些資料一般地用於索引列，但是還可以為非索引列建立統計。SQL Server維護某一個索引關鍵值的分佈統計資訊，並且使用這些統計資訊來確定在查詢程序中哪一個索引是有用的。查詢的優化依賴於這些統計資訊的分佈準確 度。查詢優化器使用這些資料樣本來決定是使用表掃描還是使用索引。當表中資料發生變化時，SQL Server週期性地自動修改統計資訊。索引統計被自動地修改，索引中的關鍵值顯著變化。統計資訊修改的頻率由索引中的資料量和資料改變數確定。例如，如 果表中有10000行資料，1000行資料修改了，那麼統計資訊可能需要修改。然而，如果只有50行記錄修改了，那麼仍然保持當前的統計資訊。除了系統自 動修改之外，使用者還可以通過執行UPDATE STATISTICS語句或者sp_updatestats系統儲存過程來手工修改統計資訊。使用UPDATE STATISTICS語句既可以修改表中的全部索引，也可以修改指定的索引。 
使用SHOWPLAN和STATISTICS IO語句可以分析索引和查詢效能。使用這些語句可以更好地調整查詢和索引。SHOWPLAN語句顯示在連線表中使用的查詢優化器的每一步以及表明使用哪一 個索引訪問資料。使用SHOWPLAN語句可以檢視指定查詢的查詢規劃。當使用SHOWPLAN語句時，應該考慮這些因素。SET SHOWPLAN_ALL語句返回的輸出結果比SET SHOWPLAN_TEXT語句返回的輸出結果詳細。然而，應用程式必須能夠處理SET SHOWPLAN_ALL語句返回的輸出結果。SHOWPLAN語句生成的資訊只能針對一個會話。如果重新連線SQL Server，那麼必須重新執行SHOWPLAN語句。STATISTICS IO語句表明輸入輸出的數量，這些輸入輸出用來返回結果集和顯示指定查詢的邏輯的和物理的I/O的資訊。可以使用這些資訊來確定是否應該重寫查詢語句或者 重新設計索引。使用STATISTICS IO語句可以檢視用來處理指定查詢的I/O資訊。 
就象SHOWPLAN語句一樣，優化器隱藏也用來 調整查詢效能。優化器隱藏可以對查詢效能提供較小的改進，並且如果索引策略發生了改變，那麼這種優化器隱藏就毫無用處了。因此，限制使用優化器隱藏，這是 因為優化器隱藏更有效率和更有柔性。當使用優化器隱藏時，考慮這些規則：指定索引名稱、當index_id為0時為使用表掃描、當index_id為1時 為使用聚簇索引；優化器隱藏覆蓋查詢優化器，如果資料或者環境發生了變化，那麼必須修改優化器隱藏。 
十一、索引調整嚮導 
索引調整嚮導是一種工具，可以分析一系列資料庫的查詢語句，提供使用一系列資料庫索引的建議，優化整個查詢語句的效能。對於查詢語句，需要指定下列內容： 
查詢語句，這是將要優化的工作量  
包含了這些表的資料庫，在這些表中，可以建立索引，提高查詢效能。
在分析中使用的表  
在分析中，考慮的約束條件，例如索引可以使用的最大磁碟空間  
這 裡指的工作量，可以來自兩個方面：使用SQL Server捕捉的軌跡和包含了SQL語句的檔案。索引調整嚮導總是基於一個已經定義好的工作量。如果一個工作量不能反映正常的操作，那麼它建議使用的索 引不是實際的工作量上效能最好的索引。索引調整嚮導呼叫查詢分析器，使用所有可能的組合評定在這個工作量中每一個查詢語句的效能。然後，建議在整個工作量 上可以提高整個查詢語句的效能的索引。如果沒有供索引調整嚮導來分析的工作量，那麼可以使用圖解器立即建立它。一旦決定跟蹤一條正常資料庫活動的描述樣 本，嚮導能夠分析這種工作量和推薦能夠提高資料庫工作效能的索引配置。 
索引調整嚮導對工作量進行分析之後，可以檢視到一系列的報告，還可以使該向導立即建立所建議的最佳索引，或者使這項工作成為一種可以排程的作業，或者生成一個包含建立這些索引的SQL語句的檔案。 
索引調整嚮導允許為SQL Server資料庫選擇和建立一種理想的索引組合和統計，而不要求對資料庫結構、工作量或者SQL Server