就象許多的PHP開(kāi)發(fā)者一樣，在剛開(kāi)始建立動(dòng)態(tài)網(wǎng)站的時(shí)候，我都是使用相對(duì)簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)。PHP在連接數(shù)據(jù)庫(kù)方面的確實(shí)是十分方便（譯者注：有些人認(rèn)為
PHP在連接不同數(shù)據(jù)庫(kù)時(shí)沒(méi)有一個(gè)統(tǒng)一的接口，不太方便，其實(shí)這可以通過(guò)一些擴(kuò)展庫(kù)來(lái)做到這一點(diǎn)），你無(wú)需看大量的設(shè)計(jì)文檔就可以建立和使用數(shù)據(jù)庫(kù)，這也
是PHP獲得成功的主要原因之一。?
??前些時(shí)候，一位頗高級(jí)的程序員居然問(wèn)我什么叫做索引，令我感到十分的驚奇，我想這絕不會(huì)是滄海一
粟，因?yàn)橛谐汕先f(wàn)的開(kāi)發(fā)者（可能大部分是使用MySQL的）都沒(méi)有受過(guò)有關(guān)數(shù)據(jù)庫(kù)的正規(guī)培訓(xùn)，盡管他們都為客戶(hù)做過(guò)一些開(kāi)發(fā)，但卻對(duì)如何為數(shù)據(jù)庫(kù)建立適
當(dāng)?shù)乃饕^少，因此我起了寫(xiě)一篇相關(guān)文章的念頭。
??最普通的情況，是為出現(xiàn)在where子句的字段建一個(gè)索引。為方便講述，我們先建立一個(gè)如下的表。
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
);
??很簡(jiǎn)單吧，不過(guò)對(duì)于要說(shuō)明這個(gè)問(wèn)題，已經(jīng)足夠了。如果你在查詢(xún)時(shí)常用類(lèi)似以下的語(yǔ)句：
SELECT?*?FROM?mytable?WHERE?category_id=1;?
??最直接的應(yīng)對(duì)之道，是為category_id建立一個(gè)簡(jiǎn)單的索引：
CREATE?INDEX?mytable_categoryid?
ON?mytable?(category_id);
??OK，搞定？先別高興，如果你有不止一個(gè)選擇條件呢？例如：
SELECT?*?FROM?mytable?WHERE?category_id=1?AND?user_id=2;
??你的第一反應(yīng)可能是，再給user_id建立一個(gè)索引。不好，這不是一個(gè)最佳的方法。你可以建立多重的索引。
CREATE?INDEX?mytable_categoryid_userid?ON?mytable?(category_id,user_id);
??注意到我在命名時(shí)的習(xí)慣了嗎？我使用"表名_字段1名_字段2名"的方式。你很快就會(huì)知道我為什么這樣做了。
??現(xiàn)在你已經(jīng)為適當(dāng)?shù)淖侄谓⒘怂饕贿^(guò)，還是有點(diǎn)不放心吧，你可能會(huì)問(wèn)，數(shù)據(jù)庫(kù)會(huì)真正用到這些索引嗎？測(cè)試一下就OK，對(duì)于大多數(shù)的數(shù)據(jù)庫(kù)來(lái)說(shuō)，這是很容易的，只要使用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的數(shù)據(jù)，可以看到該數(shù)據(jù)庫(kù)在查詢(xún)的時(shí)候使用了一個(gè)索引（一個(gè)好開(kāi)始），而且它使用的是我創(chuàng)建的第二個(gè)索引。看到我上面命名的好處了吧，你馬上知道它使用適當(dāng)?shù)乃饕恕?br />
??接著，來(lái)個(gè)稍微復(fù)雜一點(diǎn)的，如果有個(gè)ORDER?BY字句呢？不管你信不信，大多數(shù)的數(shù)據(jù)庫(kù)在使用order?by的時(shí)候，都將會(huì)從索引中受益。
SELECT?*?FROM?mytable?
??WHERE?category_id=1?AND?user_id=2
????ORDER?BY?adddate?DESC;
??有點(diǎn)迷惑了吧？很簡(jiǎn)單，就象為where字句中的字段建立一個(gè)索引一樣，也為ORDER?BY的字句中的字段建立一個(gè)索引：
CREATE?INDEX?mytable_categoryid_userid_adddate
??ON?mytable?(category_id,user_id,adddate);
??注意:?"mytable_categoryid_userid_adddate"?將會(huì)被截短為
"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的輸出，好象有點(diǎn)恐怖啊，數(shù)據(jù)庫(kù)多做了一個(gè)我們沒(méi)有要求的排序，這下知道性能如何受損了吧，看來(lái)我們對(duì)于數(shù)據(jù)庫(kù)的自身運(yùn)作是有點(diǎn)過(guò)于樂(lè)觀了，那么，給數(shù)據(jù)庫(kù)多一點(diǎn)提示吧。
??
為了跳過(guò)排序這一步，我們并不需要其它另外的索引，只要將查詢(xún)語(yǔ)句稍微改一下。這里用的是postgres，我們將給該數(shù)據(jù)庫(kù)一個(gè)額外的提示--在
ORDER?BY語(yǔ)句中，加入where語(yǔ)句中的字段。這只是一個(gè)技術(shù)上的處理，并不是必須的，因?yàn)閷?shí)際上在另外兩個(gè)字段上，并不會(huì)有任何的排序操作，不
過(guò)如果加入，postgres將會(huì)知道哪些是它應(yīng)該做的。
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
??現(xiàn)在使用我們料想的索引了，而且它還挺聰明，知道可以從索引后面開(kāi)始讀，從而避免了任何的排序。
??
以上說(shuō)得細(xì)了一點(diǎn)，不過(guò)如果你的數(shù)據(jù)庫(kù)非常巨大，并且每日的頁(yè)面請(qǐng)求達(dá)上百萬(wàn)算，我想你會(huì)獲益良多的。不過(guò)，如果你要做更為復(fù)雜的查詢(xún)呢，例如將多張表結(jié)
合起來(lái)查詢(xún)，特別是where限制字句中的字段是來(lái)自不止一個(gè)表格時(shí)，應(yīng)該怎樣處理呢？我通常都盡量避免這種做法，因?yàn)檫@樣數(shù)據(jù)庫(kù)要將各個(gè)表中的東西都結(jié)
合起來(lái)，然后再排除那些不合適的行，搞不好開(kāi)銷(xiāo)會(huì)很大。
??如果不能避免，你應(yīng)該查看每張要結(jié)合起來(lái)的表，并且使用以上的策略來(lái)建立索引，然后再用EXPLAIN命令驗(yàn)證一下是否使用了你料想中的索引。如果是的話，就OK。不是的話，你可能要建立臨時(shí)的表來(lái)將他們結(jié)合在一起，并且使用適當(dāng)?shù)乃饕?br />
??要注意的是，建立太多的索引將會(huì)影響更新和插入的速度，因?yàn)樗枰瑯痈旅總€(gè)索引文件。對(duì)于一個(gè)經(jīng)常需要更新和插入的表格，就沒(méi)有必要為一個(gè)很少使用的where字句單獨(dú)建立索引了，對(duì)于比較小的表，排序的開(kāi)銷(xiāo)不會(huì)很大，也沒(méi)有必要建立另外的索引。
??
以上介紹的只是一些十分基本的東西，其實(shí)里面的學(xué)問(wèn)也不少，單憑EXPLAIN我們是不能判定該方法是否就是最優(yōu)化的，每個(gè)數(shù)據(jù)庫(kù)都有自己的一些優(yōu)化器，
雖然可能還不太完善，但是它們都會(huì)在查詢(xún)時(shí)對(duì)比過(guò)哪種方式較快，在某些情況下，建立索引的話也未必會(huì)快，例如索引放在一個(gè)不連續(xù)的存儲(chǔ)空間時(shí)，這會(huì)增加讀
磁盤(pán)的負(fù)擔(dān)，因此，哪個(gè)是最優(yōu)，應(yīng)該通過(guò)實(shí)際的使用環(huán)境來(lái)檢驗(yàn)。
??在剛開(kāi)始的時(shí)候，如果表不大，沒(méi)有必要作索引，我的意見(jiàn)是在需要的時(shí)候才作索引，也可用一些命令來(lái)優(yōu)化表，例如MySQL可用"OPTIMIZE?TABLE"。
??綜上所述，在如何為數(shù)據(jù)庫(kù)建立恰當(dāng)?shù)乃饕矫妫銘?yīng)該有一些基本的概念了。