因為欣賞所以轉載：

http://www.cnblogs.com/cy163/archive/2008/10/27/1320798.html

http://www.cnblogs.com/lihuiyong/p/5623191.html

http://www.cnblogs.com/wb118115/p/6066171.html

前些時候，一位頗高階的程式設計師居然問我什麼叫做索引，令我感到十分的驚奇，我想這絕不會是滄海一粟，因為有成千上萬的開發者（可能大部分是使用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"。

  綜上所述，在如何為資料庫建立恰當的索引方面，你應該有一些基本的概念了。

關於MySQL索引的好處，如果正確合理設計並且使用索引的MySQL是一輛蘭博基尼的話，那麼沒有設計和使用索引的MySQL就是一個人力三輪車。對於沒有索引的表，單表查詢可能幾十萬資料就是瓶頸，而通常大型網站單日就可能會產生幾十萬甚至幾百萬的資料，沒有索引查詢會變的非常緩慢。還是以WordPress來說，其多個數據表都會對經常被查詢的欄位新增索引，比如wp_comments表中針對5個欄位設計了BTREE索引。

一個簡單的對比測試

以我去年測試的資料作為一個簡單示例，20多條資料來源隨機生成200萬條資料，平均每條資料來源都重複大概10萬次，表結構比較簡單，僅包含一個自增ID，一個char型別，一個text型別和一個int型別，單表2G大小，使用MyIASM引擎。開始測試未新增任何索引。

執行下面的SQL語句：

1	mysql> SELECT id,FROM_UNIXTIME(time) FROM article WHERE a.title='測試標題'

查詢需要的時間非常恐怖的，如果加上聯合查詢和其他一些約束條件，資料庫會瘋狂的消耗記憶體，並且會影響前端程式的執行。這時給title欄位新增一個BTREE索引：

1	mysql> ALTER TABLE article ADD INDEX index_article_title ON title(200);

再次執行上述查詢語句，其對比非常明顯：

MySQL索引的概念

索引是一種特殊的檔案(InnoDB資料表上的索引是表空間的一個組成部分)，它們包含著對資料表裡所有記錄的引用指標。更通俗的說，資料庫索引好比是一本書前面的目錄，能加快資料庫的查詢速度。上述SQL語句，在沒有索引的情況下，資料庫會遍歷全部200條資料後選擇符合條件的；而有了相應的索引之後，資料庫會直接在索引中查詢符合條件的選項。如果我們把SQL語句換成“SELECT * FROM article WHERE id=2000000”，那麼你是希望資料庫按照順序讀取完200萬行資料以後給你結果還是直接在索引中定位呢？上面的兩個圖片鮮明的用時對比已經給出了答案（注：一般資料庫預設都會為主鍵生成索引）。

索引分為聚簇索引和非聚簇索引兩種，聚簇索引是按照資料存放的物理位置為順序的，而非聚簇索引就不一樣了；聚簇索引能提高多行檢索的速度，而非聚簇索引對於單行的檢索很快。

MySQL索引的型別

1. 普通索引

這是最基本的索引，它沒有任何限制，比如上文中為title欄位建立的索引就是一個普通索引，MyIASM中預設的BTREE型別的索引，也是我們大多數情況下用到的索引。

01

–直接建立索引

02	CREATE INDEX index_name ON table(column(length))

03	–修改表結構的方式新增索引

04	ALTER TABLE table_name ADD INDEX index_name ON (column(length))

05	–建立表的時候同時建立索引

相關推薦