資料庫索引的最大作用就是加快查詢速度,它能從根本上減少需要掃表的記錄行的數量,資料庫索引就是資料庫的資料結構,進一步說則是該資料結構中儲存了一張表中某一列的所有值,也就是說索引是基於資料表中的某一列所建立的。
資料庫索引是為了增加查詢速度而將表格欄位附加的一種識別。看過很多人機械的理解索引的概念,認為增加索引只有好處沒有壞處。這裡想把之前的索引學習筆記總結一下:
先明白為什麼索引會增加速度,DB在執行一條Sql語句的時候,預設的方式是根據搜尋條件進行全表掃描,遇到符合條件的就加入搜尋結果集合。如果我們對某一字段增加索引,查詢時就會先去索引列表中一次定位到特定值的行數,大大減少遍歷匹配的行數,所以能明顯增加查詢的速度。那麼在任何時候都該加索引麼呢?這裡有幾個反例:1、如果每次都需要取到所有表記錄,無論如何都必須進行全表掃描了,那麼是否加索引也沒有意義了。 2.對非唯一的字段,例如「性別」這種大量重複值的字段,增加索引也沒有意義。 3.對於記錄比較少的表,增加索引不會帶來速度的優化反而浪費了存儲空間,因為索引是需要存儲空間的,而且有個致命缺點是對於update/insert/delete的每次執行,字段的索引都必須重新計算更新。
那麼什麼時候適合加上索引呢?我們來看一個Mysql手冊中舉的例子,這裡有一個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個表格的連結,並且包含了許多搜尋條件例如大小比較,Like匹配等。在沒有索引的情況下Mysql需要執行的掃描行數是77721876行。而我們透過在companyID和groupLabel兩個欄位上加上索引之後,掃描的行數只需要134行。在Mysql中可以透過Explain Select來查看掃描次數。可以看出來在這種聯表和複雜搜尋條件的情況下,索引帶來的效能提升遠比它所佔據的磁碟空間重要得多。
那麼索引是如何達成的呢?大多數DB廠商實作索引都是基於一種資料結構-B樹。因為B樹的特點就是適合在磁碟等直接儲存設備上組織動態查找表。 B樹的定義是這樣的:一棵m(m>=3)階的B樹是滿足下列條件的m叉樹:
1、每個結點包含如下作用域(j, p0 , k1, p1, k2, p2, ... ki, pi) 其中j是關鍵字個數,p是孩子指針
2、所有葉子結點在同一層上,層數等於樹高h
3、每個非根結點包含的關鍵字個數滿足[m/2-1]<=j<=m-1
4、若樹非空,則根至少有1個關鍵字,若根非葉子,則至少有2棵子樹,至多有m棵子樹
看一個B樹的例子,針對26個英文字母的B樹可以這樣構造:
可以看到在這棵B樹搜尋英文字母複雜度只為o(m),在資料量比較大的情況下,這樣的結構可以大大增加查詢速度。然而有另一個資料結構查詢的虛度比B樹更快-散列表。 Hash表的定義是這樣的:設所有可能出現的關鍵字集合為u,實際發生儲存的關鍵字記為k,而|k|比|u|小很多。雜湊方法是透過雜湊函數h將u映射到表T[0,m-1]的下標上,這樣u中的關鍵字為變量,以h為函數運算結果即為對應結點的儲存位址。從而達到可以在o(1)的時間內完成查找。
然而散列表有一個缺陷,那就是雜湊衝突,即兩個關鍵字透過雜湊函數計算出了相同的結果。設m和n分別表示散列表的長度和填滿的結點數,n/m為散列表的填裝因子,因子越大,表示散列衝突的機會越大。
因為有這樣的缺陷,所以資料庫不會使用散列表來做為索引的預設實現,Mysql宣稱會根據執行查詢格式嘗試將基於磁碟的B樹索引轉變為和合適的雜湊索引以追求進一步提高搜尋速度。我想其它資料庫廠商也會有類似的策略,畢竟在資料庫戰場上,搜尋速度和管理安全一樣是非常重要的競爭點。
以上是資料庫索引的作用的詳細內容。更多資訊請關注PHP中文網其他相關文章!