數據庫索引
本詞條由“科普中國”百科科學詞條編寫與應用工作項目 審覈 。
索引是對數據庫表中一列或多列的值進行排序的一種結構，使用索引可快速訪問數據庫表中的特定信息。如果想按特定職員的姓來查找他或她，則與在表中搜索所有的行相比，索引有助於更快地獲取信息。
索引的一個主要目的就是加快檢索表中數據的方法，亦即能協助信息搜索者儘快的找到符合限制條件的記錄ID的輔助數據結構。
中文名
外文名
index
分 類
聚簇索引 非聚簇索引
詳 述
提高系統的性能
目 的
加快對錶中記錄的查找或排序
優 點
迅速
目錄
簡介
索引是對數據庫表中一個或多個列（例如，employee 表的姓名 (name) 列）的值進行排序的結構。
例如這樣一個查詢：select * from table1 where id=10000。如果沒有索引，必須遍歷整個表，直到ID等於10000的這一行被找到爲止；有了索引之後(必須是在ID這一列上建立的索引)，即可在索引中查找。由於索引是經過某種算法優化過的，因而查找次數要少的多。可見，索引是用來定位的。
從數據搜索實現的角度來看，索引也是另外一類文件/記錄，它包含着可以指示出相關數據記錄的各種記錄。其中，每一索引都有一個相對應的搜索碼，字符段的任意一個子集都能夠形成一個搜索碼。這樣，索引就相當於所有數據目錄項的一個集合，它能爲既定的搜索碼值的所有數據目錄項提供定位所需的各種有效支持 [1] 。
基本概念
-
搜索碼。它表示的是記錄各種字符段的一個集合，它可以是一個或者是多個字符段的任意序列組合，並不是惟一的一個標識記錄。
-
數據目錄項。即爲索引的相關元素，在建立索引的過程中，數據目錄項一般具有各種不同的選擇方式。
-
記錄ID。每一個/段索引在存儲內容中惟一的一個標識符。
主要種類
數據庫索引好比是一本書前面的目錄，能
SQL Server的B樹結構
加快數據庫的查詢速度。索引分爲聚簇索引和非聚簇索引兩種，聚簇索引 是按照數據存放的物理位置爲順序的，而非聚簇索引就不一樣了；聚簇索引能提高多行檢索的速度，而非聚簇索引對於單行的檢索很快。
根據數據庫的功能，可以在數據庫設計器中創建三種索引：唯一索引、主鍵索引和聚集索引。有關數據庫所支持的索引功能的詳細信息，請參見數據庫文檔。
提示：儘管唯一索引有助於定位信息，但爲獲得最佳性能結果，建議改用主鍵或唯一約束。
唯一索引
唯一索引是不允許其中任何兩行具有相同索引值的索引。當現有數據中存在重複的鍵值時，大多數數據庫不允許將新創建的唯一索引與表一起保存。數據庫還可能防止添加將在表中創建重複鍵值的新數據。例如，如果在employee表中職員的姓(lname)上創建了唯一索引，則任何兩個員工都不能同姓。
主鍵索引
數據庫表經常有一列或多列組合，其值唯一標識表中的每一行。該列稱爲表的主鍵。在數據庫關係圖中爲表定義主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對數據的快速訪問。
聚集索引
在聚集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個聚集索引。如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的數據訪問速度。聚集索引和非聚集索引的區別，如字典默認按字母順序排序，讀者如知道某個字的讀音可根據字母順序快速定位。因此聚集索引和表的內容是在一起的。如讀者需查詢某個生僻字，則需按字典前面的索引，舉例按偏旁進行定位，找到該字對應的頁數，再打開對應頁數找到該字。這種通過兩個地方而查詢到某個字的方式就如非聚集索引。
索引列
可以基於數據庫表中的單列或多列創建索引。多列索引可以區分其中一列可能有相同值的行。如果經常同時搜索兩列或多列或按兩列或多列排序時，索引也很有幫助。例如，如果經常在同一查詢中爲姓和名兩列設置判據，那麼在這兩列上創建多列索引將很有意義。
檢查查詢的WHERE和JOIN子句。在任一子句中包括的每一列都是索引可以選擇的對象。對新索引進行試驗以檢查它對運行查詢性能的影響。考慮已在表上創建的索引數量。最好避免在單個表上有很多索引。檢查已在表上創建的索引的定義。最好避免包含共享列的重疊索引。
檢查某列中唯一數據值的數量，並將該數量與表中的行數進行比較。比較的結果就是該列的可選擇性，這有助於確定該列是否適合建立索引，如果適合，確定索引的類型。
基本特點
建立索引的目的是加快對錶中記錄的查找或排序。爲表設置索引要付出代價的：一是增加了數據庫的存儲空間，二是在插入和修改數據時要花費較多的時間(因爲索引也要隨之變動)。數據庫索引就是爲了提高表的搜索效率而對某些字段中的值建立的目錄 。
創建索引可以大大提高系統的性能。第一，通過創建唯一性索引，可以保證數據庫表中每一行數據的唯一性。第二，可以大大加快數據的檢索速度，這也是創建索引的最主要的原因。第三，可以加速表和表之間的連接，特別是在實現數據的參考完整性方面特別有意義。第四，在使用分組和排序子句進行數據檢索時，同樣可以顯著減少查詢中分組和排序的時間。第五，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。
因爲，增加索引也有許多不利的方面。第一，創建索引和維護索引要耗費時間，這種時間隨着數據量的增加而增加。第二，索引需要佔物理空間，除了數據表佔數據空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。第三，當對錶中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。
優點
通過建立索引可以極大地提高在數據庫中獲取所需信息的速度，同時還能提高服務器處理相關搜索請求的效率，從這個方面來看它具有以下優點 [1] ：
-
在設計數據庫時，通過創建一個惟一的索引，能夠在索引和信息之間形成一對一的映射式的對應關係，增加數據的惟一性特點。
-
能提高數據的搜索及檢索速度，符合數據庫建立的初衷。
-
能夠加快表與表之間的連接速度，這對於提高數據的參考完整性方面具有重要作用。
-
在信息檢索過程中，若使用分組及排序子句進行時，通過建立索引能有效的減少檢索過程中所需的分組及排序時間，提高檢索效率。
-
建立索引之後，在信息查詢過程中可以使用優化隱藏器，這對於提高整個信息檢索系統的性能具有重要意義。
缺點
雖然索引的建立在提高檢索效率方面具有諸多積極的作用，但還是存在下列缺點 [1] ：
-
在數據庫建立過程中，需花費較多的時間去建立並維護索引，特別是隨着數據總量的增加，所花費的時間將不斷遞增。
-
在數據庫中創建的索引需要佔用一定的物理存儲空間，這其中就包括數據表所佔的數據空間以及所創建的每一個索引所佔用的物理空間，如果有必要建立起聚簇索引，所佔用的空間還將進一步的增加
-
在對錶中的數據進行修改時，例如對其進行增加、刪除或者是修改操作時，索引還需要進行動態的維護，這給數據庫的維護速度帶來了一定的麻煩。
注意事項
索引是建立在數據庫表中的某些列的上面。在創建索引的時候，應該考慮在哪些列上可以創建索引，在哪些列上不能創建索引。一般來說，應該在這些列上創建索引：
在經常需要搜索的列上，可以加快搜索的速度；
在作爲主鍵的列上，強制該列的唯一性和組織表中數據的排列結構；
在經常用在連接的列上，這些列主要是一些外鍵，可以加快連接的速度；在經常需要根據範圍進行搜索的列上創建索引，因爲索引已經排序，其指定的範圍是連續的；
在經常需要排序的列上創建索引，因爲索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；
在經常使用在WHERE子句中的列上面創建索引，加快條件的判斷速度。
同樣，對於有些列不應該創建索引。一般來說，不應該創建索引的這些列具有下列特點：
第一，對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因爲，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。
第二，對於那些只有很少數據值的列也不應該增加索引。這是因爲，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大。增加索引，並不能明顯加快檢索速度。
第三，對於那些定義爲text, image和bit數據類型的列不應該增加索引。這是因爲，這些列的數據量要麼相當大，要麼取值很少,不利於使用索引。
第四，當修改性能遠遠大於檢索性能時，不應該創建索引。這是因爲，修改性能和檢索性能是互相矛盾的。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。因此，當修改操作遠遠多於檢索操作時，不應該創建索引。
操作案例
|
1 2 3 4 5 6 |
|
如果在查詢時常用類似以下的語句：
SELECT * FROM mytable WHERE category_id=1;
最直接的應對之道，是爲category_id建立一個簡單的索引：
CREATE INDEX mytable_categoryid ON mytable (category_id);
OK.如果有不止一個選擇條件呢？例如：
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
第一反應可能是，再給user_id建立一個索引。不好，這不是一個最佳的方法。可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
注意到在命名時的習慣了嗎？使用"表名_字段1名_字段2名"的方式。很快就會知道爲什麼這樣做了。
現在已經爲適當的字段建立了索引，不過，還是有點不放心吧，可能會問，數據庫會真正用到這些索引嗎？測試一下就OK，對於大多數的數據庫來說，這是很容易的，只要使用EXPLAIN命令：
|
1 2 3 4 5 6 7 8 |
|
以上是postgres的數據，可以看到該數據庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是創建的第二個索引。看到上面命名的好處了吧，馬上知道它使用適當的索引了。
接着，來個稍微複雜一點的，如果有個ORDERBY 子句呢？不管你信不信，大多數的數據庫在使用orderby的時候，都將會從索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很簡單，就像爲where子句中的字段建立一個索引一樣，也爲ORDER BY的子句中的字段建立一個索引：
CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);
注意:"mytable_categoryid_userid_adddate"將會被截短爲"mytable_categoryid_userid_addda"
|
1 2 3 4 5 6 7 8 9 |
|
看看EXPLAIN的輸出，數據庫多做了一個沒有要求的排序，這下知道性能如何受損了吧，看來對於數據庫的自身運作是有點過於樂觀了，那麼，給數據庫多一點提示吧。
爲了跳過排序這一步，並不需要其它另外的索引，只要將查詢語句稍微改一下。這裏用的是postgres，將給該數據庫一個額外的提示--在ORDER BY語句中，加入where語句中的字段。這只是一個技術上的處理，並不是必須的，因爲實際上在另外兩個字段上，並不會有任何的排序操作，不過如果加入，postgres將會知道哪些是它應該做的。
|
1 2 3 4 5 6 7 |
|
現在使用料想的索引了，而且它還挺聰明，知道可以從索引後面開始讀，從而避免了任何的排序。
以上說得細了一點，不過如果數據庫非常巨大，並且每日的頁面請求達上百萬算，想會獲益良多的。不過，如果要做更爲複雜的查詢呢，例如將多張表結合起來查詢，特別是where限制字句中的字段是來自不止一個表格時，應該怎樣處理呢？通常都儘量避免這種做法，因爲這樣數據庫要將各個表中的東西都結合起來，然後再排除那些不合適的行，搞不好開銷會很大。
如果不能避免，應該查看每張要結合起來的表，並且使用以上的策略來建立索引，然後再用EXPLAIN命令驗證一下是否使用了料想中的索引。如果是的話，就OK。不是的話，可能要建立臨時的表來將他們結合在一起，並且使用適當的索引。
要注意的是，建立太多的索引將會影響更新和插入的速度，因爲它需要同樣更新每個索引文件。對於一個經常需要更新和插入的表格，就沒有必要爲一個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
以上介紹的只是一些十分基本的東西，其實裏面的學問也不少，單憑EXPLAIN是不能判定該方法是否就是最優化的，每個數據庫都有自己的一些優化器，雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續的存儲空間時，這會增加讀磁盤的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。
在剛開始的時候，如果表不大，沒有必要作索引，意見是在需要的時候才作索引，也可用一些命令來優化表，例如MySQL可用"OPTIMIZETABLE"。