原創文章，轉載請註明出處！

本文目的：通過通俗易懂的方式介紹索引的由來和各類索引的優缺點，文章只求讓讀者對索引由一個感性的瞭解，並未對索引的效能等做詳細探討。不足之處歡迎批評指正。

一 為什麼要用索引？

存在即合理，索引的出現一定有它的原因，否則早已消失。那為什麼要用索引呢？假如現在我們有一份商品清單表，這份清單包括這麼幾項內容：商品的編號，商品的名稱，商品的價格和和商品的庫存。如果表裡只記錄了100個商品，那我們想查詢一個編號為xx的商品多少錢時，最簡單的方法就是從上到下一項一項地挨著看一遍，碰巧了可能第一個就是這樣就一下查到了，可是要是碰不巧那就得看到第100個了。要是商品清單中有一萬個商品或者有百萬甚至上億個商品呢？如果碰不巧豈不是得看到天荒地老才能查到？所以在資料量很大的時候，提高查詢效率非常地重要。而索引出現就是為了解決這個問題。雖然索引種類有很多，形式各不相同，但無論怎麼變索引的目的只有一個就是提高搜尋效率。

那什麼是索引呢？彆著急，我們還是回到商品清單上來。現在我們假設商品清單裡有1億條商品記錄。為了提高查詢的速度，我想到一個辦法。那就是把商品編號這一列單獨拿出來，然後提前把它從小到大排個序。這樣一來，再查詢編號為xx的商品時，我就可以用二分法進行查找了，二分法查詢的時間複雜度是O(logn),那麼從這個已經排好序的編號列表中查到我想要的編號最壞也就不到30次，這可快了不是一點兒半點兒啊。但是光找到這個編號不想啊還是查不到價格，怎麼辦？那我們就在取編號出來的時候也把編號對應的這條記錄的地址也拿出來，這樣找到了編號，就找到了這條商品記錄的地址，也就能一下查到它的價格了。

這個例子中，所有拿出來的編號和地址就組成了一個索引，某條編號和它對應的地址組成了一個索引項。簡單來說，索引就是建立在資料記錄的某個或某些屬性,如例子中的編號，之上的，並且經過重新組織以提高搜尋效率的資料的集合。本質上，索引還是資料，只是為了提高搜尋效率它有它的組織形式，如上圖的順序結構，除此之外它還可能組織成樹形結構等等。如果你對資料結構不太熟悉，還是需要先去熟悉一下的。

二 索引的分類

在提高資料記錄的搜尋效率方面，沒有那種索引是萬能的，只有相對的好還是不好，因此索引也衍生出了很多種類。下面我們就具體來探討一下不同種類索引。

1 線性索引

線性索引顧名思義，索引的索引項是線性排列的。此外，線性索引還有一個要求就是索引項是順序排列的不能是無序的。就像上例中的編號是從小到大線性排列的，它就是一個線性索引。

1.1 稠密索引

什麼是稠密索引呢？在上面的例子中，我們其實建立的就是一個稠密索引。我們把所有的商品編號全部都拿出來進行了排序，因此商品清單裡的每條商品記錄與索引項都是一一對應的。我們有1億條商品記錄，就有1億個索引項。這樣的索引就是稠密索引。之所以叫稠密索引就是因為索引項的數量比較多，跟商品記錄是一樣的。採用二分法的情況下，稠密索引的最壞情況下約需要查詢logn次，時間複雜度為O(logn)。

稠密索引的好處是我們可以像上面的例子一樣採用像二分法一樣的演算法來提高搜尋效率，其效果確實是顯而易見的。但是呢，稠密索引也是有很麻煩的缺點，那就是當資料量很大時它的索引項太多了，索引項多就表示資料量很大，資料量大就意味著需要更多的儲存空間。而且由於索引始終要維持有序，插入或刪除記錄時，維護成本也將很高。如果一條索引1KB，那麼5億條索引就得將近5GB，這都放到記憶體中還是有點吃不消啊。可能有人要說了，我的硬碟1T放5GB綽綽有餘。可是，如果真的把索引資料都放到硬碟，我們仍需要把它的一部分載入到記憶體中，而且需要反覆載入不同的部分，這時就得與硬碟進行反覆的IO操作，然而機械硬碟的IO操作是很費時的，這樣效率還是得不到很大的提升啊。要是能把索引項變少都放到記憶體裡，而且還能用像二分法一樣的演算法進行查詢那就好了。這樣的好事有麼？當然有。稀疏索引就解決了這個問題。