溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

數(shù)據(jù)庫中索引有什么用

發(fā)布時間:2021-01-15 10:52:54 來源:億速云 閱讀:278 作者:小新 欄目:數(shù)據(jù)庫

這篇文章主要介紹數(shù)據(jù)庫中索引有什么用,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!

數(shù)據(jù)庫索引的最大作用就是加快查詢速度,它能從根本上減少需要掃表的記錄行的數(shù)量,數(shù)據(jù)庫索引就是數(shù)據(jù)庫的數(shù)據(jù)結構,進一步說則是該數(shù)據(jù)結構中存儲了一張表中某一列的所有值,也就是說索引是基于數(shù)據(jù)表中的某一列創(chuàng)建的。

數(shù)據(jù)庫索引是為了增加查詢速度而對表字段附加的一種標識。見過很多人機械的理解索引的概念,認為增加索引只有好處沒有壞處。這里想把之前的索引學習筆記總結一下:

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

那么在什么時候適合加上索引呢?我們看一個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個表的聯(lián)接,并且包括了許多搜索條件比如大小比較,Like匹配等。在沒有索引的情況下Mysql需要執(zhí)行的掃描行數(shù)是77721876行。而我們通過在companyID和groupLabel兩個字段上加上索引之后,掃描的行數(shù)只需要134行。在Mysql中可以通過Explain Select來查看掃描次數(shù)。可以看出來在這種聯(lián)表和復雜搜索條件的情況下,索引帶來的性能提升遠比它所占據(jù)的磁盤空間要重要得多。

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

1、每個結點包括如下作用域(j, p0, k1, p1, k2, p2, ... ki, pi) 其中j是關鍵字個數(shù),p是孩子指針

2、所有葉子結點在同一層上,層數(shù)等于樹高h

3、每個非根結點包含的關鍵字個數(shù)滿足[m/2-1]<=j<=m-1

4、若樹非空,則根至少有1個關鍵字,若根非葉子,則至少有2棵子樹,至多有m棵子樹

看一個B樹的例子,針對26個英文字母的B樹可以這樣構造:

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

以上是“數(shù)據(jù)庫中索引有什么用”這篇文章的所有內容,感謝各位的閱讀!希望分享的內容對大家有幫助,更多相關知識,歡迎關注億速云行業(yè)資訊頻道!

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內容。

AI