這里想把之前的索引學(xué)習(xí)筆記總結(jié)一下：

    首先明白為什么索引會(huì)增加速度，DB在執(zhí)行一條Sql語句的時(shí)候，默認(rèn)的方式是根據(jù)搜索條件進(jìn)行全表掃描，遇到匹配條件的就加入搜索結(jié)果集合。如果我們對(duì)某一字段增加索引，查詢時(shí)就會(huì)先去索引列表中一次定位到特定值的行數(shù)，大大減少遍歷匹配的行數(shù)，所以能明顯增加查詢的速度。那么在任何時(shí)候都應(yīng)該加索引么？這里有幾個(gè)反例：1、如果每次都需要取到所有表記錄，無論如何都必須進(jìn)行全表掃描了，那么是否加索引也沒有意義了。2、對(duì)非唯一的字段，例如“性別”這種大量重復(fù)值的字段，增加索引也沒有什么意義。3、對(duì)于記錄比較少的表，增加索引不會(huì)帶來速度的優(yōu)化反而浪費(fèi)了存儲(chǔ)空間，因?yàn)樗饕切枰鎯?chǔ)空間的，而且有個(gè)致命缺點(diǎn)是對(duì)于update/insert/delete的每次執(zhí)行，字段的索引都必須重新計(jì)算更新。

    那么在什么時(shí)候適合加上索引呢？我們看一個(gè)Mysql手冊(cè)中舉的例子，這里有一條sql語句：

    SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees >= 0 AND c.companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')

    這條語句涉及3個(gè)表的聯(lián)接，并且包括了許多搜索條件比如大小比較，Like匹配等。在沒有索引的情況下Mysql需要執(zhí)行的掃描行數(shù)是 77721876行。而我們通過在companyID和groupLabel兩個(gè)字段上加上索引之后，掃描的行數(shù)只需要134行。在Mysql中可以通過 Explain Select來查看掃描次數(shù)?？梢钥闯鰜碓谶@種聯(lián)表和復(fù)雜搜索條件的情況下，索引帶來的性能提升遠(yuǎn)比它所占據(jù)的磁盤空間要重要得多。

    那么索引是如何實(shí)現(xiàn)的呢？大多數(shù)DB廠商實(shí)現(xiàn)索引都是基于一種數(shù)據(jù)結(jié)構(gòu)——B樹。因?yàn)锽樹的特點(diǎn)就是適合在磁盤等直接存儲(chǔ)設(shè)備上組織動(dòng)態(tài)查找表。B樹的定義是這樣的：一棵m(m>=3)階的B樹是滿足下列條件的m叉樹：

    1、每個(gè)結(jié)點(diǎn)包括如下作用域(j, p0, k1, p1, k2, p2, ... ki, pi) 其中j是關(guān)鍵字個(gè)數(shù)，p是孩子指針

    2、所有葉子結(jié)點(diǎn)在同一層上，層數(shù)等于樹高h(yuǎn)

    3、每個(gè)非根結(jié)點(diǎn)包含的關(guān)鍵字個(gè)數(shù)滿足[m/2-1]<=j<=m-1

    4、若樹非空，則根至少有1個(gè)關(guān)鍵字，若根非葉子，則至少有2棵子樹，至多有m棵子樹

    看一個(gè)B樹的例子，針對(duì)26個(gè)英文字母的B樹可以這樣構(gòu)造：

    可以看到在這棵B樹搜索英文字母復(fù)雜度只為o(m)，在數(shù)據(jù)量比較大的情況下，這樣的結(jié)構(gòu)可以大大增加查詢速度。然而有另外一種數(shù)據(jù)結(jié)構(gòu)查詢的虛度比B樹更快——散列表。Hash表的定義是這樣的：設(shè)所有可能出現(xiàn)的關(guān)鍵字集合為u，實(shí)際發(fā)生存儲(chǔ)的關(guān)鍵字記為k，而|k|比|u|小很多。散列方法是通過散列函數(shù)h將u映射到表T[0,m-1]的下標(biāo)上，這樣u中的關(guān)鍵字為變量，以h為函數(shù)運(yùn)算結(jié)果即為相應(yīng)結(jié)點(diǎn)的存儲(chǔ)地址。從而達(dá)到可以在o(1)的時(shí)間內(nèi)完成查找。
    然而散列表有一個(gè)缺陷，那就是散列沖突，即兩個(gè)關(guān)鍵字通過散列函數(shù)計(jì)算出了相同的結(jié)果。設(shè)m和n分別表示散列表的長(zhǎng)度和填滿的結(jié)點(diǎn)數(shù)，n/m為散列表的填裝因子，因子越大，表示散列沖突的機(jī)會(huì)越大。
    因?yàn)橛羞@樣的缺陷，所以數(shù)據(jù)庫不會(huì)使用散列表來做為索引的默認(rèn)實(shí)現(xiàn)，Mysql宣稱會(huì)根據(jù)執(zhí)行查詢格式嘗試將基于磁盤的B樹索引轉(zhuǎn)變?yōu)楹秃线m的散列索引以追求進(jìn)一步提高搜索速度。我想其它數(shù)據(jù)庫廠商也會(huì)有類似的策略，畢竟在數(shù)據(jù)庫戰(zhàn)場(chǎng)上，搜索速度和管理安全一樣是非常重要的競(jìng)爭(zhēng)點(diǎn)。

基本概念介紹：

索引

使用索引可快速訪問數(shù)據(jù)庫表中的特定信息。索引是對(duì)數(shù)據(jù)庫表中一列或多列的值進(jìn)行排序的一種結(jié)構(gòu)，例如 employee 表的姓（lname）列。如果要按姓查找特定職員，與必須搜索表中的所有行相比，索引會(huì)幫助您更快地獲得該信息。

索引提供指向存儲(chǔ)在表的指定列中的數(shù)據(jù)值的指針，然后根據(jù)您指定的排序順序?qū)@些指針排序。數(shù)據(jù)庫使用索引的方式與您使用書籍中的索引的方式很相似：它搜索索引以找到特定值，然后順指針找到包含該值的行。

在數(shù)據(jù)庫關(guān)系圖中，您可以在選定表的“索引/鍵”屬性頁中創(chuàng)建、編輯或刪除每個(gè)索引類型。當(dāng)保存索引所附加到的表，或保存該表所在的關(guān)系圖時(shí)，索引將保存在數(shù)據(jù)庫中。有關(guān)詳細(xì)信息，請(qǐng)參見創(chuàng)建索引。

注意;并非所有的數(shù)據(jù)庫都以相同的方式使用索引。有關(guān)更多信息，請(qǐng)參見數(shù)據(jù)庫服務(wù)器注意事項(xiàng)，或者查閱數(shù)據(jù)庫文檔。

作為通用規(guī)則，只有當(dāng)經(jīng)常查詢索引列中的數(shù)據(jù)時(shí)，才需要在表上創(chuàng)建索引。索引占用磁盤空間，并且降低添加、刪除和更新行的速度。在多數(shù)情況下，索引用于數(shù)據(jù)檢索的速度優(yōu)勢(shì)大大超過它的。

索引列

可以基于數(shù)據(jù)庫表中的單列或多列創(chuàng)建索引。多列索引使您可以區(qū)分其中一列可能有相同值的行。

如果經(jīng)常同時(shí)搜索兩列或多列或按兩列或多列排序時(shí)，索引也很有幫助。例如，如果經(jīng)常在同一查詢中為姓和名兩列設(shè)置判據(jù)，那么在這兩列上創(chuàng)建多列索引將很有意義。

確定索引的有效性：

• 檢查查詢的 WHERE 和 JOIN 子句。在任一子句中包括的每一列都是索引可以選擇的對(duì)象。
• 對(duì)新索引進(jìn)行試驗(yàn)以檢查它對(duì)運(yùn)行查詢性能的影響。
• 考慮已在表上創(chuàng)建的索引數(shù)量。最好避免在單個(gè)表上有很多索引。
• 檢查已在表上創(chuàng)建的索引的定義。最好避免包含共享列的重疊索引。
• 檢查某列中唯一數(shù)據(jù)值的數(shù)量，并將該數(shù)量與表中的行數(shù)進(jìn)行比較。比較的結(jié)果就是該列的可選擇性，這有助于確定該列是否適合建立索引，如果適合，確定索引的類型。

索引類型

根據(jù)數(shù)據(jù)庫的功能，可以在數(shù)據(jù)庫設(shè)計(jì)器中創(chuàng)建三種索引：唯一索引、主鍵索引和聚集索引。有關(guān)數(shù)據(jù)庫所支持的索引功能的詳細(xì)信息，請(qǐng)參見數(shù)據(jù)庫文檔。

提示：盡管唯一索引有助于定位信息，但為獲得最佳性能結(jié)果，建議改用主鍵或唯一約束。

唯一索引

唯一索引是不允許其中任何兩行具有相同索引值的索引。

當(dāng)現(xiàn)有數(shù)據(jù)中存在重復(fù)的鍵值時(shí)，大多數(shù)數(shù)據(jù)庫不允許將新創(chuàng)建的唯一索引與表一起保存。數(shù)據(jù)庫還可能防止添加將在表中創(chuàng)建重復(fù)鍵值的新數(shù)據(jù)。例如，如果在 employee 表中職員的姓 (lname) 上創(chuàng)建了唯一索引，則任何兩個(gè)員工都不能同姓。

主鍵索引

數(shù)據(jù)庫表經(jīng)常有一列或列組合，其值唯一標(biāo)識(shí)表中的每一行。該列稱為表的主鍵。

在數(shù)據(jù)庫關(guān)系圖中為表定義主鍵將自動(dòng)創(chuàng)建主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個(gè)值都唯一。當(dāng)在查詢中使用主鍵索引時(shí)，它還允許對(duì)數(shù)據(jù)的快速訪問。

聚集索引

在聚集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個(gè)表只能包含一個(gè)聚集索引。

如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的數(shù)據(jù)訪問速度。

建立方式和注意事項(xiàng)

最普通的情況，是為出現(xiàn)在where子句的字段建一個(gè)索引。為方便講述，我們先建立一個(gè)如下的表。

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

);

如果你在查詢時(shí)常用類似以下的語句：

　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ù)淖侄谓⒘怂饕?，不過，還是有點(diǎn)不放心吧，你可能會(huì)問，數(shù)據(jù)庫會(huì)真正用到這些索引嗎？測(cè)試一下就OK，對(duì)于大多數(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ù)庫在查詢的時(shí)候使用了一個(gè)索引（一個(gè)好開始），而且它使用的是我創(chuàng)建的第二個(gè)索引?？吹轿疑厦婷暮锰幜税?，你馬上知道它使用適當(dāng)?shù)乃饕恕?/P>

接著，來個(gè)稍微復(fù)雜一點(diǎn)的，如果有個(gè)ORDER BY字句呢？不管你信不信，大多數(shù)的數(shù)據(jù)庫在使用order by的時(shí)候，都將會(huì)從索引中受益。

　SELECT * FROM mytable

WHERE category_id=1 AND user_id=2

　ORDER BY adddate DESC;

很簡(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的輸出，數(shù)據(jù)庫多做了一個(gè)我們沒有要求的排序，這下知道性能如何受損了吧，看來我們對(duì)于數(shù)據(jù)庫的自身運(yùn)作是有點(diǎn)過于樂觀了，那么，給數(shù)據(jù)庫多一點(diǎn)提示吧。

為了跳過排序這一步，我們并不需要其它另外的索引，只要將查詢語句稍微改一下。這里用的是postgres，我們將給該數(shù)據(jù)庫一個(gè)額外的提示--在 ORDER BY語句中，加入where語句中的字段。這只是一個(gè)技術(shù)上的處理，并不是必須的，因?yàn)閷?shí)際上在另外兩個(gè)字段上，并不會(huì)有任何的排序操作，不過如果加入，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)在使用我們料想的索引了，而且它還挺聰明，知道可以從索引后面開始讀，從而避免了任何的排序。

以上說得細(xì)了一點(diǎn)，不過如果你的數(shù)據(jù)庫非常巨大，并且每日的頁面請(qǐng)求達(dá)上百萬算，我想你會(huì)獲益良多的。不過，如果你要做更為復(fù)雜的查詢呢，例如將多張表結(jié)合起來查詢，特別是where限制字句中的字段是來自不止一個(gè)表格時(shí)，應(yīng)該怎樣處理呢？我通常都盡量避免這種做法，因?yàn)檫@樣數(shù)據(jù)庫要將各個(gè)表中的東西都結(jié)合起來，然后再排除那些不合適的行，搞不好開銷會(huì)很大。

如果不能避免，你應(yīng)該查看每張要結(jié)合起來的表，并且使用以上的策略來建立索引，然后再用EXPLAIN命令驗(yàn)證一下是否使用了你料想中的索引。如果是的話，就OK。不是的話，你可能要建立臨時(shí)的表來將他們結(jié)合在一起，并且使用適當(dāng)?shù)乃饕?

要注意的是，建立太多的索引將會(huì)影響更新和插入的速度，因?yàn)樗枰瑯痈旅總€(gè)索引文件。對(duì)于一個(gè)經(jīng)常需要更新和插入的表格，就沒有必要為一個(gè)很少使用的where字句單獨(dú)建立索引了，對(duì)于比較小的表，排序的開銷不會(huì)很大，也沒有必要建立另外的索引。

以上介紹的只是一些十分基本的東西，其實(shí)里面的學(xué)問也不少，單憑EXPLAIN我們是不能判定該方法是否就是最優(yōu)化的，每個(gè)數(shù)據(jù)庫都有自己的一些優(yōu)化器，雖然可能還不太完善，但是它們都會(huì)在查詢時(shí)對(duì)比過哪種方式較快，在某些情況下，建立索引的話也未必會(huì)快，例如索引放在一個(gè)不連續(xù)的存儲(chǔ)空間時(shí)，這會(huì)增加讀磁盤的負(fù)擔(dān)，因此，哪個(gè)是最優(yōu)，應(yīng)該通過實(shí)際的使用環(huán)境來檢驗(yàn)。

在剛開始的時(shí)候，如果表不大，沒有必要作索引，我的意見是在需要的時(shí)候才作索引，也可用一些命令來優(yōu)化表，例如MySQL可用"OPTIMIZE TABLE"。

綜上所述，在如何為數(shù)據(jù)庫建立恰當(dāng)?shù)乃饕矫?，你?yīng)該有一些基本的概念了。