最普通的情況，是為出現(xiàn)在where子句的字段建一個索引。為方便講述，我們先建立一個如下的表。
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;
最直接的應(yīng)對之道，是為category_id建立一個簡單的索引：
　CREATE INDEX mytable_categoryid
　ON mytable (category_id);
OK.如果你有不止一個選擇條件呢？例如：
　SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
你的第一反應(yīng)可能是，再給user_id建立一個索引。不好，這不是一個最佳的方法。你可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable (category_id,user_id);
注意到我在命名時的習(xí)慣了嗎？我使用"表名_字段1名_字段2名"的方式。你很快就會知道我為什么這樣做了。
現(xiàn)在你已經(jīng)為適當(dāng)?shù)淖侄谓⒘怂饕贿^，還是有點不放心吧，你可能會問，數(shù)據(jù)庫會真正用到這些索引嗎？測試一下就OK，對于大多數(shù)的數(shù)據(jù)庫來說，這是很容易的，只要使用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ù)庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是我創(chuàng)建的第二個索引。看到我上面命名的好處了吧，你馬上知道它使用適當(dāng)?shù)乃饕恕?/p>

接著，來個稍微復(fù)雜一點的，如果有個ORDER BY字句呢？不管你信不信，大多數(shù)的數(shù)據(jù)庫在使用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的輸出，數(shù)據(jù)庫多做了一個我們沒有要求的排序，這下知道性能如何受損了吧，看來我們對于數(shù)據(jù)庫的自身運作是有點過于樂觀了，那么，給數(shù)據(jù)庫多一點提示吧。
為 了跳過排序這一步，我們并不需要其它另外的索引，只要將查詢語句稍微改一下。這里用的是postgres，我們將給該數(shù)據(jù)庫一個額外的提示--在 ORDER BY語句中，加入where語句中的字段。這只是一個技術(shù)上的處理，并不是必須的，因為實際上在另外兩個字段上，并不會有任何的排序操作，不過如果加 入，postgres將會知道哪些是它應(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)在使用我們料想的索引了，而且它還挺聰明，知道可以從索引后面開始讀，從而避免了任何的排序。
以 上說得細(xì)了一點，不過如果你的數(shù)據(jù)庫非常巨大，并且每日的頁面請求達(dá)上百萬算，我想你會獲益良多的。不過，如果你要做更為復(fù)雜的查詢呢，例如將多張表結(jié)合 起來查詢，特別是where限制字句中的字段是來自不止一個表格時，應(yīng)該怎樣處理呢？我通常都盡量避免這種做法，因為這樣數(shù)據(jù)庫要將各個表中的東西都結(jié)合 起來，然后再排除那些不合適的行，搞不好開銷會很大。
如果不能避免，你應(yīng)該查看每張要結(jié)合起來的表，并且使用以上的策略來建立索引，然后再用EXPLAIN命令驗證一下是否使用了你料想中的索引。如果是的話，就OK。不是的話，你可能要建立臨時的表來將他們結(jié)合在一起，并且使用適當(dāng)?shù)乃饕?
要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引文件。對于一個經(jīng)常需要更新和插入的表格，就沒有必要為一個很少使用的where字句單獨建立索引了，對于比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
以 上介紹的只是一些十分基本的東西，其實里面的學(xué)問也不少，單憑EXPLAIN我們是不能判定該方法是否就是最優(yōu)化的，每個數(shù)據(jù)庫都有自己的一些優(yōu)化器，雖 然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續(xù)的存儲空間時，這會增加讀磁 盤的負(fù)擔(dān)，因此，哪個是最優(yōu)，應(yīng)該通過實際的使用環(huán)境來檢驗。
在剛開始的時候，如果表不大，沒有必要作索引，我的意見是在需要的時候才作索引，也可用一些命令來優(yōu)化表，例如MySQL可用"OPTIMIZE TABLE"。
綜上所述，在如何為數(shù)據(jù)庫建立恰當(dāng)?shù)乃饕矫妫銘?yīng)該有一些基本的概念了。