mysql資料庫索引詳解用法

索引

使用索引可快速存取資料庫教程表中的特定資訊。索引是對資料庫表中一列或多列的值進行排序的一種結構，例如 employee 表的姓（lname）列。如果要按姓尋找特定職員，與必須搜尋表中的所有行相比，索引會協助您更快地獲得該資訊。

索引提供指向儲存在表的指定列中的資料值的指標，然後根據您指定的排序次序對這些指標排序。資料庫使用索引的方式與您使用書籍中的索引的方式很相似：它搜尋索引以找到特定值，然後順指標找到包含該值的行。

在資料庫圖表中，您可以在選定表的“索引/鍵”屬性頁面中建立、編輯或刪除每個索引類型。當儲存索引所附加到的表，或儲存該表所在的關係圖時，索引將儲存在資料庫中。有關詳細資料，請參見建立索引。

注意;並非所有的資料庫都以相同的方式使用索引。有關更多資訊，請參見資料庫伺服器注意事項，或者查閱資料庫文檔。
作為通用規則，只有當經常查詢索引列中的資料時，才需要在表上建立索引。索引佔用磁碟空間，並且降低添加、刪除和更新行的速度。在多數情況下，索引用於資料檢索的速度優勢大大超過它的。

索引列
可以基於資料庫表中的單列或多列建立索引。多列索引使您可以區分其中一列可能有相同值的行。

如果經常同時搜尋兩列或多列或按兩列或多列排序時，索引也很有協助。例如，如果經常在同一查詢中為姓和名兩列設定判據，那麼在這兩列上建立多列索引將很有意義。

確定索引的有效性：

檢查查詢的 WHERE 和 JOIN 子句。在任一子句中包括的每一列都是索引可以選擇的對象。
對新索引進行實驗以檢查它對執行查詢效能的影響。
考慮已在表上建立的索引數量。最好避免在單個表上有很多索引。
檢查已在表上建立的索引的定義。最好避免包含共用列的重疊索引。
檢查某列中唯一資料值的數量，並將該數量與表中的行數進行比較。比較的結果就是該列的可選擇性，這有助於確定該列是否適合建立索引，如果適合，確定索引的類型。
索引類型
根據資料庫的功能，可以在資料庫設計器中建立三種索引：唯一索引、主鍵索引和叢集索引。有關資料庫所支援的索引功能的詳細資料，請參見資料庫文檔。

提示：儘管唯一索引有助於定位資訊，但為獲得最佳效能結果，建議改用主鍵或唯一約束。
唯一索引
唯一索引是不允許其中任何兩行具有相同索引值的索引。

當現有資料中存在重複的索引值時，大多數資料庫不允許將新建立的唯一索引與表一起儲存。資料庫還可能防止添加將在表中建立重複索引值的新資料。例如，如果在 employee 表中職員的姓 (lname) 上建立了唯一索引，則任何兩個員工都不能同姓。

主鍵索引

資料庫表經常有一列或列組合，其值唯一標識表中的每一行。該列稱為表的主鍵。

在資料庫圖表中為表定義主鍵將自動建立主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對資料的快速存取。

叢集索引

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

如果某索引不是叢集索引，則表中行的物理順序與索引值的邏輯順序不匹配。與非叢集索引相比，叢集索引通常提供更快的資料訪問速度。

 

建立方式和注意事項

最普通的情況，是為出現在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;

最直接的應對之道，是為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"。