就象許多的PHP開發者一樣，在剛開始建立動態網站的時候，我都是使用相對簡單的數據結構。PHP在連接數據庫方面的確實是十分方便（譯者注：有些人認為
PHP在連接不同數據庫時沒有一個統一的接口，不太方便，其實這可以通過一些擴展庫來做到這一點），你無需看大量的設計文檔就可以建立和使用數據庫，這也
是PHP獲得成功的主要原因之一。?
??前些時候，一位頗高級的程序員居然問我什么叫做索引，令我感到十分的驚奇，我想這絕不會是滄海一
粟，因為有成千上萬的開發者（可能大部分是使用MySQL的）都沒有受過有關數據庫的正規培訓，盡管他們都為客戶做過一些開發，但卻對如何為數據庫建立適
當的索引所知較少，因此我起了寫一篇相關文章的念頭。
??最普通的情況，是為出現在where子句的字段建一個索引。為方便講述，我們先建立一個如下的表。
Code代碼如下:CREATE?TABLE?mytable?(
id?serial?primary?key,
category_id?int?not?null?default?0,
user_id?int?not?null?default?0,
adddate?int?not?null?default?0
);
??很簡單吧，不過對于要說明這個問題，已經足夠了。如果你在查詢時常用類似以下的語句：
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?(exactly?as?I?expected)?
NOTICE:?QUERY?PLAN:
Index?Scan?using?mytable_categoryid_userid?on?
??mytable?(cost=0.00..2.02?rows=1?width=16)
EXPLAIN
??以上是postgres的數據，可以看到該數據庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是我創建的第二個索引。看到我上面命名的好處了吧，你馬上知道它使用適當的索引了。
??接著，來個稍微復雜一點的，如果有個ORDER?BY字句呢？不管你信不信，大多數的數據庫在使用order?by的時候，都將會從索引中受益。
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"
CREATE
??EXPLAIN?SELECT?*?FROM?mytable
WHERE?category_id=1?AND?user_id=2
ORDER?BY?adddate?DESC;
NOTICE:?QUERY?PLAN:
Sort?(cost=2.03..2.03?rows=1?width=16)
->?Index?Scan?using?mytable_categoryid_userid_addda?
on?mytable?(cost=0.00..2.02?rows=1?width=16)
EXPLAIN
??看看EXPLAIN的輸出，好象有點恐怖啊，數據庫多做了一個我們沒有要求的排序，這下知道性能如何受損了吧，看來我們對于數據庫的自身運作是有點過于樂觀了，那么，給數據庫多一點提示吧。
??
為了跳過排序這一步，我們并不需要其它另外的索引，只要將查詢語句稍微改一下。這里用的是postgres，我們將給該數據庫一個額外的提示--在
ORDER?BY語句中，加入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_addda?on?mytable?
??(cost=0.00..2.02?rows=1?width=16)
EXPLAIN
??現在使用我們料想的索引了，而且它還挺聰明，知道可以從索引后面開始讀，從而避免了任何的排序。
??
以上說得細了一點，不過如果你的數據庫非常巨大，并且每日的頁面請求達上百萬算，我想你會獲益良多的。不過，如果你要做更為復雜的查詢呢，例如將多張表結
合起來查詢，特別是where限制字句中的字段是來自不止一個表格時，應該怎樣處理呢？我通常都盡量避免這種做法，因為這樣數據庫要將各個表中的東西都結
合起來，然后再排除那些不合適的行，搞不好開銷會很大。
??如果不能避免，你應該查看每張要結合起來的表，并且使用以上的策略來建立索引，然后再用EXPLAIN命令驗證一下是否使用了你料想中的索引。如果是的話，就OK。不是的話，你可能要建立臨時的表來將他們結合在一起，并且使用適當的索引。
??要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引文件。對于一個經常需要更新和插入的表格，就沒有必要為一個很少使用的where字句單獨建立索引了，對于比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
??
以上介紹的只是一些十分基本的東西，其實里面的學問也不少，單憑EXPLAIN我們是不能判定該方法是否就是最優化的，每個數據庫都有自己的一些優化器，
雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續的存儲空間時，這會增加讀
磁盤的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。
??在剛開始的時候，如果表不大，沒有必要作索引，我的意見是在需要的時候才作索引，也可用一些命令來優化表，例如MySQL可用"OPTIMIZE?TABLE"。
??綜上所述，在如何為數據庫建立恰當的索引方面，你應該有一些基本的概念了。