索引的優勢和缺點，設計數據庫的人員必看--轉載

時間 2019-12-06

標籤索引優勢缺點設計數據庫人員轉載欄目 SQL 简体版

原文原文鏈接

1、爲何要建立索引呢（優勢）？
這是由於，建立索引能夠大大提升系統的性能。
第一，   經過建立惟一性索引，能夠保證數據庫表中每一行數據的惟一性。
第二，   能夠大大加快數據的檢索速度，這也是建立索引的最主要的緣由。
第三，   能夠加速表和表之間的鏈接，特別是在實現數據的參考完整性方面特別有意義。
第四，   在使用分組和排序子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間。
第五，   經過使用索引，能夠在查詢的過程當中，使用優化隱藏器，提升系統的性能。

2、創建方向索引的不利因素（缺點）
也許會有人要問：增長索引有如此多的優勢，爲何不對錶中的每個列建立一個索引呢？這種想法當然有其合理性，然而也有其片面性。雖然，索引有許多優勢，可是，爲表中的每個列都增長索引，是很是不明智的。這是由於，增長索引也有許多不利的一個方面。

第一，   建立索引和維護索引要耗費時間，這種時間隨着數據量的增長而增長。
第二，   索引須要佔物理空間，除了數據表佔數據空間以外，每個索引還要佔必定的物理空間，若是要創建聚簇索引，那麼須要的空間就會更大。
第三，   當對錶中的數據進行增長、刪除和修改的時候，索引也要動態的維護，這樣就下降了數據的維護速度。

3、建立方向索引的準則
索引是創建在數據庫表中的某些列的上面。所以，在建立索引的時候，應該仔細考慮在哪些列上能夠建立索引，在哪些列上不能建立索引。
通常來講，應該在這些列上建立索引。
第一，   在常常須要搜索的列上，能夠加快搜索的速度；
第二，   在做爲主鍵的列上，強制該列的惟一性和組織表中數據的排列結構；
第三，   在常常用在鏈接的列上，這些列主要是一些外鍵，能夠加快鏈接的速度；
第四，   在常常須要根據範圍進行搜索的列上建立索引，由於索引已經排序，其指定的範圍是連續的；
第五，   在常常須要排序的列上建立索引，由於索引已經排序，這樣查詢能夠利用索引的排序，加快排序查詢時間；
第六，   在常用在WHERE子句中的列上面建立索引，加快條件的判斷速度。

一樣，對於有些列不該該建立索引。通常來講，不該該建立索引的的這些列具備下列特色：
第一，             對於那些在查詢中不多使用或者參考的列不該該建立索引。這是由於，既然這些列不多使用到，所以有索引或者無索引，並不能提升查詢速度。相反，因爲增長了索引，反而下降了系統的維護速度和增大了空間需求。
第二，             對於那些只有不多數據值的列也不該該增長索引。這是由於，因爲這些列的取值不多，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即須要在表中搜索的數據行的比例很大。增長索引，並不能明顯加快檢索速度。
第三，             對於那些定義爲text, image和bit數據類型的列不該該增長索引。這是由於，這些列的數據量要麼至關大，要麼取值不多。
第四，             當修改性能遠遠大於檢索性能時，不該該建立索引。這是由於，修改性能和檢索性能是互相矛盾的。當增長索引時，會提升檢索性能，可是會下降修改性能。當減小索引時，會提升修改性能，下降檢索性能。所以，當修改性能遠遠大於檢索性能時，不該該建立索引。
4、建立索引的方法
建立索引有多種方法，這些方法包括直接建立索引的方法和間接建立索引的方法。
第一，   直接建立索引，例如使用CREATE INDEX語句或者使用建立索引向導。
第二，   間接建立索引，例如在表中定義主鍵約束或者惟一性鍵約束時，同時也建立了索引。
雖然，這兩種方法均可以建立索引，可是，它們建立索引的具體內容是有區別的。
使用CREATE INDEX語句或者使用建立索引向導來建立索引，這是最基本的索引建立方式，而且這種方法最具備柔性，能夠定製建立出符合本身須要的索引。在使用這種方式建立索引時，可使用許多選項，例如指定數據頁的充滿度、進行排序、整理統計信息等，這樣能夠優化索引。使用這種方法，能夠指定索引的類型、惟一性和複合性，也就是說，既能夠建立聚簇索引，也能夠建立非聚簇索引，既能夠在一個列上建立索引，也能夠在兩個或者兩個以上的列上建立索引。
經過定義主鍵約束或者惟一性鍵約束，也能夠間接建立索引。主鍵約束是一種保持數據完整性的邏輯，它限制表中的記錄有相同的主鍵記錄。在建立主鍵約束時，系統自動建立了一個惟一性的聚簇索引。雖然，在邏輯上，主鍵約束是一種重要的結構，可是，在物理結構上，與主鍵約束相對應的結構是惟一性的聚簇索引。換句話說，在物理實現上，不存在主鍵約束，而只存在惟一性的聚簇索引。一樣，在建立惟一性鍵約束時，也同時建立了索引，這種索引則是惟一性的非聚簇索引。所以，當使用約束建立索引時，索引的類型和特徵基本上都已經肯定了，由用戶定製的餘地比較小。
當在表上定義主鍵或者惟一性鍵約束時，若是表中已經有了使用CREATE INDEX語句建立的標準索引時，那麼主鍵約束或者惟一性鍵約束建立的索引覆蓋之前建立的標準索引。也就是說，主鍵約束或者惟一性鍵約束建立的索引的優先級高於使用CREATE INDEX語句建立的索引。
5、索引的特徵
    索引有兩個特徵，即惟一性索引和複合索引。
惟一性索引保證在索引列中的所有數據是惟一的，不會包含冗餘數據。若是表中已經有一個主鍵約束或者惟一性鍵約束，那麼當建立表或者修改表時，SQL Server自動建立一個惟一性索引。然而，若是必須保證惟一性，那麼應該建立主鍵約束或者惟一性鍵約束，而不是建立一個惟一性索引。當建立惟一性索引時，應該認真考慮這些規則：當在表中建立主鍵約束或者惟一性鍵約束時，SQL Server自動建立一個惟一性索引；若是表中已經包含有數據，那麼當建立索引時，SQL Server檢查表中已有數據的冗餘性；每當使用插入語句插入數據或者使用修改語句修改數據時，SQL Server檢查數據的冗餘性：若是有冗餘值，那麼SQL Server取消該語句的執行，而且返回一個錯誤消息；確保表中的每一行數據都有一個惟一值，這樣能夠確保每個實體均可以惟一確認；只能在能夠保證明體完整性的列上建立惟一性索引，例如，不能在人事表中的姓名列上建立惟一性索引，由於人們能夠有相同的姓名。
複合索引就是一個索引建立在兩個列或者多個列上。在搜索時，當兩個或者多個列做爲一個關鍵值時，最好在這些列上建立複合索引。當建立複合索引時，應該考慮這些規則：最多能夠把16個列合併成一個單獨的複合索引，構成複合索引的列的總長度不能超過900字節，也就是說複合列的長度不能太長；在複合索引中，全部的列必須來自同一個表中，不能跨表創建複合列；在複合索引中，列的排列順序是很是重要的，所以要認真排列列的順序，原則上，應該首先定義最惟一的列，例如在（COL1，COL2）上的索引與在（COL2，COL1）上的索引是不相同的，由於兩個索引的列的順序不一樣；爲了使查詢優化器使用複合索引，查詢語句中的WHERE子句必須參考複合索引中第一個列；當表中有多個關鍵列時，複合索引是很是有用的；使用複合索引能夠提升查詢性能，減小在一個表中所建立的索引數量。
6、索引的類型
根據索引的順序與數據表的物理順序是否相同，能夠把索引分紅兩種類型。一種是數據表的物理順序與索引順序相同的聚簇索引，另外一種是數據表的物理順序與索引順序不相同的非聚簇索引。
7、聚簇索引的體系結構
索引的結構相似於樹狀結構，樹的頂部稱爲葉級，樹的其它部分稱爲非葉級，樹的根部在非葉級中。一樣，在聚簇索引中，聚簇索引的葉級和非葉級構成了一個樹狀結構，索引的最低級是葉級。在聚簇索引中，表中的數據所在的數據頁是葉級，在葉級之上的索引頁是非葉級，索引數據所在的索引頁是非葉級。在聚簇索引中，數據值的順序老是按照升序排列。
應該在表中常常搜索的列或者按照順序訪問的列上建立聚簇索引。當建立聚簇索引時，應該考慮這些因素：每個表只能有一個聚簇索引，由於表中數據的物理順序只能有一個；表中行的物理順序和索引中行的物理順序是相同的，在建立任何非聚簇索引以前建立聚簇索引，這是由於聚簇索引改變了表中行的物理順序，數據行按照必定的順序排列，而且自動維護這個順序；關鍵值的惟一性要麼使用UNIQUE關鍵字明確維護，要麼由一個內部的惟一標識符明確維護，這些惟一性標識符是系統本身使用的，用戶不能訪問；聚簇索引的平均大小大約是數據表的百分之五，可是，實際的聚簇索引的大小經常根據索引列的大小變化而變化；在索引的建立過程當中，SQL Server臨時使用當前數據庫的磁盤空間，當建立聚簇索引時，須要1.2倍的表空間的大小，所以，必定要保證有足夠的空間來建立聚簇索引。
當系統訪問表中的數據時，首先肯定在相應的列上是否存在有索引和該索引是否對要檢索的數據有意義。若是索引存在而且該索引很是有意義，那麼系統使用該索引訪問表中的記錄。系統從索引開始瀏覽到數據，索引瀏覽則從樹狀索引的根部開始。從根部開始，搜索值與每個關鍵值相比較，肯定搜索值是否大於或者等於關鍵值。這一步重複進行，直到碰上一個比搜索值大的關鍵值，或者該搜索值大於或者等於索引頁上全部的關鍵值爲止。
8、非聚簇索引的體系結構
非聚簇索引的結構也是樹狀結構，與聚簇索引的結構很是相似，可是也有明顯的不一樣。
在非聚簇索引中，葉級僅包含關鍵值，而沒有包含數據行。非聚簇索引表示行的邏輯順序。    非聚簇索引有兩種體系結構：一種體系結構是在沒有聚簇索引的表上建立非聚簇索引，另外一種體系結構是在有聚簇索引的表上建立非聚簇索引。
若是一個數據表中沒有聚簇索引，那麼這個數據表也稱爲數據堆。當非聚簇索引在數據堆的頂部建立時，系統使用索引頁中的行標識符指向數據頁中的記錄。行標識符存儲了數據所在位置的信息。數據堆是經過使用索引分配圖（IAM）頁來維護的。IAM頁包含了數據堆所在簇的存儲信息。在系統表sysindexes中，有一個指針指向了與數據堆相關的第一個IAM頁。系統使用IAM頁在數據堆中瀏覽和尋找能夠插入新的記錄行的空間。這些數據頁和在這些數據頁中的記錄沒有任何的順序而且也沒有連接在一塊兒。在這些數據頁之間的惟一的鏈接是IAM中記錄的順序。當在數據堆上建立了非聚簇索引時，葉級中包含了指向數據頁的行標識符。行標識符指定記錄行的邏輯順序，由文件ID、頁號和行ID組成。這些行的標識符維持惟一性。非聚簇索引的葉級頁的順序不一樣於表中數據的物理順序。這些關鍵值在葉級中以升序維持。
當非聚簇索引建立在有聚簇索引的表上的時候，系統使用索引頁中的指向聚簇索引的聚簇鍵。聚簇鍵存儲了數據的位置信息。若是某一個表有聚簇索引，那麼非聚簇索引的葉級包含了映射到聚簇鍵的聚簇鍵值，而不是映射到物理的行標識符。當系統訪問有非聚簇索引的表中數據時，而且這種非聚簇索引建立在聚簇索引上，那麼它首先從非聚簇索引來找到指向聚簇索引的指針，而後經過使用聚簇索引來找到數據。
    當須要以多種方式檢索數據時，非聚簇索引是很是有用的。當建立非聚簇索引時，要考慮這些狀況：在缺省狀況下，所建立的索引是非聚簇索引；在每個表上面，能夠建立很少於249個非聚簇索引，而聚簇索引最多隻能有一個。
系統如何訪問表中的數據
通常地，系統訪問數據庫中的數據，可使用兩種方法：表掃描和索引查找。第一種方法是表掃描，就是指系統將指針放置在該表的表頭數據所在的數據頁上，而後按照數據頁的排列順序，一頁一頁地從前向後掃描該表數據所佔有的所有數據頁，直至掃描完表中的所有記錄。在掃描時，若是找到符合查詢條件的記錄，那麼就將這條記錄挑選出來。最後，將所有挑選出來符合查詢語句條件的記錄顯示出來。第二種方法是使用索引查找。索引是一種樹狀結構，其中存儲了關鍵字和指向包含關鍵字所在記錄的數據頁的指針。當使用索引查找時，系統沿着索引的樹狀結構，根據索引中關鍵字和指針，找到符合查詢條件的的記錄。最後，將所有查找到的符合查詢語句條件的記錄顯示出來。
    在SQL Server中，當訪問數據庫中的數據時，由SQL Server肯定該表中是否有索引存在。若是沒有索引，那麼SQL Server使用表掃描的方法訪問數據庫中的數據。查詢處理器根據分佈的統計信息生成該查詢語句的優化執行規劃，以提升訪問數據的效率爲目標，肯定是使用表掃描仍是使用索引。
9、索引的選項
    在建立索引時，能夠指定一些選項，經過使用這些選項，能夠優化索引的性能。這些選項包括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選項。
10、索引的維護
爲了維護系統性能，索引在建立以後，因爲頻繁地對數據進行增長、刪除、修改等操做使得索引頁發生碎塊，所以，必須對索引進行維護。
使用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時爲使用聚簇索引；優化器隱藏覆蓋查詢優化器，若是數據或者環境發生了變化，那麼必須修改優化器隱藏。
11、索引調整嚮導
索引調整嚮導是一種工具，能夠分析一系列數據庫的查詢語句，提供使用一系列數據庫索引的建議，優化整個查詢語句的性能。對於查詢語句，須要指定下列內容：
查詢語句，這是將要優化的工做量
包含了這些表的數據庫，在這些表中，能夠建立索引，提升查詢性能。
在分析中使用的表
在分析中，考慮的約束條件，例如索引可使用的最大磁盤空間
這裏指的工做量，能夠來自兩個方面：使用SQL Server捕捉的軌跡和包含了SQL語句的文件。索引調整嚮導老是基於一個已經定義好的工做量。若是一個工做量不能反映正常的操做，那麼它建議使用的索引不是實際的工做量上性能最好的索引。索引調整嚮導調用查詢分析器，使用全部可能的組合評定在這個工做量中每個查詢語句的性能。而後，建議在整個工做量上能夠提升整個查詢語句的性能的索引。若是沒有供索引調整嚮導來分析的工做量，那麼可使用圖解器當即建立它。一旦決定跟蹤一條正常數據庫活動的描述樣本，嚮導可以分析這種工做量和推薦可以提升數據庫工做性能的索引配置。
索引調整嚮導對工做量進行分析以後，能夠查看到一系列的報告，還可使該向導當即建立所建議的最佳索引，或者使這項工做成爲一種能夠調度的做業，或者生成一個包含建立這些索引的SQL語句的文件。
索引調整嚮導容許爲SQL Server數據庫選擇和建立一種理想的索引組合和統計，而不要求對數據庫結構、工做量或者SQL Server閱讀 java