編輯本段索引

　　資料庫索引好比是一本書前面的目錄，能加快資料庫的查詢速度。 　　例如這樣一個查詢：select * from table1 where id=44。如果沒有索引，必須遍歷整個表，直到ID等於44的這一行被找到為止；有了索引之後(必須是在ID這一列上建立的索引)，直接在索引裡面找44（也就是在ID這一列找），就可以得知這一行的位置，也就是找到了這一行。可見，索引是用來定位的。 　　索引分為聚簇索引和非聚簇索引兩種，聚簇索引 是按照資料存放的物理位置為順序的，而非聚簇索引就不一樣了；聚簇索引能提高多行檢索的速度，而非聚簇索引對於單行的檢索很快。

編輯本段索引的優缺點

概述

　　建立索引的目的是加快對錶中記錄的查詢或排序。 　　為表設定索引要付出代價的：一是增加了資料庫的儲存空間，二是在插入和修改資料時要花費較多的時間(因為索引也要隨之變動)。

詳述

　　建立索引可以大大提高系統的效能。第一，通過建立唯一性索引，可以保證資料庫表中每一行資料的唯一性。第二，可以大大加快資料的檢索速度，這也是建立索引的最主要的原因。第三，可以加速表和表之間的連線，特別是在實現資料的參考完整性方面特別有意義。第四，在使用分組和排序子句進行資料檢索時，同樣可以顯著減少查詢中分組和排序的時間。第五，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的效能。 　　也許會有人要問：增加索引有如此多的優點，為什麼不對錶中的每一個列建立一個索引呢？因為，增加索引也有許多不利的方面。第一，建立索引和維護索引要耗費時間，這種時間隨著資料量的增加而增加。第二，索引需要佔物理空間，除了資料表佔資料空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。第三，當對錶中的資料進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了資料的維護速度。 　　索引是建立在資料庫表中的某些列的上面。在建立索引的時候，應該考慮在哪些列上可以建立索引，在哪些列上不能建立索引。一般來說，應該在這些列上建立索引： 　　在經常需要搜尋的列上，可以加快搜尋的速度； 　　在作為主鍵的列上，強制該列的唯一性和組織表中資料的排列結構； 　　在經常用在連線的列上，這些列主要是一些外來鍵，可以加快連線的速度；在經常需要根據範圍進行搜尋的列上建立索引，因為索引已經排序，其指定的範圍是連續的； 　　在經常需要排序的列上建立索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間； 　　在經常使用在WHERE子句中的列上面建立索引，加快條件的判斷速度。 　　同樣，對於有些列不應該建立索引。一般來說，不應該建立索引的的這些列具有下列特點： 　　第一，對於那些在查詢中很少使用或者參考的列不應該建立索引。這是因為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。 　　第二，對於那些只有很少資料值的列也不應該增加索引。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的資料行佔了表中資料行的很大比例，即需要在表中搜尋的資料行的比例很大。增加索引，並不能明顯加快檢索速度。 　　第三，對於那些定義為text, image和bit資料型別的列不應該增加索引。這是因為，這些列的資料量要麼相當大，要麼取值很少,不利於使用索引。 　　第四，當修改效能遠遠大於檢索效能時，不應該建立索引。這是因為，修改效能和檢索效能是互相矛盾的。當增加索引時，會提高檢索效能，但是會降低修改效能。當減少索引時，會提高修改效能，降低檢索效能。因此，當修改操作遠遠多於檢索操作時，不應該建立索引。

編輯本段索引列

　　可以基於資料庫表中的單列或多列建立索引。多列索引可以區分其中一列可能有相同值的行。 　　如果經常同時搜尋兩列或多列或按兩列或多列排序時，索引也很有幫助。例如，如果經常在同一查詢中為姓和名兩列設定判據，那麼在這兩列上建立多列索引將很有意義。 　　確定索引的有效性： 　　檢查查詢的WHERE和JOIN子句。在任一子句中包括的每一列都是索引可以選擇的物件。 　　對新索引進行試驗以檢查它對執行查詢效能的影響。 　　考慮已在表上建立的索引數量。最好避免在單個表上有很多索引。 　　檢查已在表上建立的索引的定義。最好避免包含共享列的重疊索引。 　　檢查某列中唯一資料值的數量，並將該數量與表中的行數進行比較。比較的結果就是該列的可選擇性，這有助於確定該列是否適合建立索引，如果適合，確定索引的型別。

編輯本段型別

　　根據資料庫的功能，可以在資料庫設計器中建立三種索引：唯一索引、主鍵索引和聚集索引。有關資料庫所支援的索引功能的詳細資訊，請參見資料庫文件。 　　提示：儘管唯一索引有助於定位資訊，但為獲得最佳效能結果，建議改用主鍵或唯一約束。 　　唯一索引 唯一索引是不允許其中任何兩行具有相同索引值的索引。 　　當現有資料中存在重複的鍵值時，大多數資料庫不允許將新建立的唯一索引與表一起儲存。資料庫還可能防止新增將在表中建立重複鍵值的新資料。例如，如果在employee表中職員的姓(lname)上建立了唯一索引，則任何兩個員工都不能同姓。 　　主鍵索引 　　資料庫表經常有一列或列組合，其值唯一標識表中的每一行。該列稱為表的主鍵。 　　在資料庫關係圖中為表定義主鍵將自動建立主鍵索引，主鍵索引是唯一索引的特定型別。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對資料的快速訪問。 　　聚集索引 　　在聚集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個聚集索引。 　　如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的資料訪問速度。

編輯本段建立索引

　　最普通的情況，是為出現在where子句的欄位建一個索引。為方便講述，先建立一個如下的表。 　　CREATETABLEmytable( 　　idserial primary key, 　　category_id int not null default0, 　　user_id int not null default0, 　　adddate int not null default0 　　); 　　如果在查詢時常用類似以下的語句： 　　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命令： 　　EXPLAIN 　　SELECT * FROM mytable 　　WHERE category_id=1 AND user_id=2; 　　This is what Postgres 7.1 returns (exactlyasI expected) 　　NOTICE:QUERY PLAN: 　　Index Scan using mytable_categoryid_useridon 　　mytable(cost=0.00..2.02 rows=1 width=16) 　　EXPLAIN 　　以上是postgres的資料，可以看到該資料庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是建立的第二個索引。看到上面命名的好處了吧，馬上知道它使用適當的索引了。 　　接著，來個稍微複雜一點的，如果有個ORDERBY字句呢？不管你信不信，大多數的資料庫在使用orderby的時候，都將會從索引中受益。 　　SELECT * FROM mytable 　　WHERE category_id=1 AND user_id=2 　　ORDER BY add date DESC; 　　很簡單，就象為where字句中的欄位建立一個索引一樣，也為ORDERBY的字句中的欄位建立一個索引： 　　CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate); 　　注意:"mytable_categoryid_userid_adddate"將會被截短為"mytable_categoryid_userid_addda" 　　CREATE 　　EXPLAIN SELECT * FROM mytable 　　WHERE category_id=1 AND user_id=2 　　ORDER BY add date DESC; 　　NOTICE:QUERY PLAN: 　　Sort(cost=2.03..2.03 rows=1 width=16) 　　->Index Scanusing mytable_categoryid_userid_addda 　　onmytable(cost=0.00..2.02 rows=1 width=16) 　　EXPLAIN 　　看看EXPLAIN的輸出，資料庫多做了一個沒有要求的排序，這下知道效能如何受損了吧，看來對於資料庫的自身運作是有點過於樂觀了，那麼，給資料庫多一點提示吧。 　　為了跳過排序這一步，並不需要其它另外的索引，只要將查詢語句稍微改一下。這裡用的是postgres，將給該資料庫一個額外的提示--在ORDERBY語句中，加入where語句中的欄位。這只是一個技術上的處理，並不是必須的，因為實際上在另外兩個欄位上，並不會有任何的排序操作，不過如果加入，postgres將會知道哪些是它應該做的。 　　EXPLAIN SELECT * FROM mytable 　　WHERE category_id=1 AND user_id=2 　　ORDER BY category_id DESC,user_id DESC,adddate DESC; 　　NOTICE:QUERY PLAN: 　　Index Scan Backward using 　　mytable_categoryid_userid_add daon my table 　　(cost=0.00..2.02 rows=1 width=16) 　　EXPLAIN 　　現在使用料想的索引了，而且它還挺聰明，知道可以從索引後面開始讀，從而避免了任何的排序。 　　以上說得細了一點，不過如果資料庫非常巨大，並且每日的頁面請求達上百萬算，想會獲益良多的。不過，如果要做更為複雜的查詢呢，例如將多張表結合起來查詢，特別是where限制字句中的欄位是來自不止一個表格時，應該怎樣處理呢？通常都儘量避免這種做法，因為這樣資料庫要將各個表中的東西都結合起來，然後再排除那些不合適的行，搞不好開銷會很大。 　　如果不能避免，應該檢視每張要結合起來的表，並且使用以上的策略來建立索引，然後再用EXPLAIN命令驗證一下是否使用了料想中的索引。如果是的話，就OK。不是的話，可能要建立臨時的表來將他們結合在一起，並且使用適當的索引。 　　要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引檔案。對於一個經常需要更新和插入的表格，就沒有必要為一個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。 　　以上介紹的只是一些十分基本的東西，其實裡面的學問也不少，單憑EXPLAIN是不能判定該方法是否就是最優化的，每個資料庫都有自己的一些優化器，雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續的儲存空間時，這會增加讀磁碟的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。 　　在剛開始的時候，如果表不大，沒有必要作索引，意見是在需要的時候才作索引，也可用一些命令來優化表，例如MySQL可用"OPTIMIZETABLE"。