程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> mysql數據庫索引詳解用法

mysql數據庫索引詳解用法

編輯: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"。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved