共計 1828 個字符，預計需要花費 5 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

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

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

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

首先明白為什么索引會增加速度，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 樹索引轉變為和合適的散列索引以追求進一步提高搜索速度。我想其它數據庫廠商也會有類似的策略，畢竟在數據庫戰場上，搜索速度和管理安全一樣是非常重要的競爭點。

以上是“數據庫中索引有什么用”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！

向 AI 問一下細節