【58沈劍 架構師之路】數據庫索引，究竟是什麼作的？

問題1. 數據庫爲何要設計索引？

 

圖書館存了1000W本圖書，要從中找到《架構師之路》，一本本查，要查到何時去？

因而，圖書管理員設計了一套規則：

(1)一樓放歷史類，二樓放文學類，三樓放IT類…

(2)IT類，又分軟件類，硬件類…

(3)軟件類，又按照書名音序排序…

以便快速找到一本書。

 

與之類比，數據庫存儲了1000W條數據，要從中找到name=」shenjian」的記錄，一條條查，要查到何時去？

因而，要有索引，用於提高數據庫的查找速度。

 

問題2. 哈希(hash)比樹(tree)更快，索引結構爲何要設計成樹型？

 

加速查找速度的數據結構，常見的有兩類：

(1)哈希，例如HashMap，查詢/插入/修改/刪除的平均時間複雜度都是O(1)；

(2)樹，例如平衡二叉搜索樹，查詢/插入/修改/刪除的平均時間複雜度都是O(lg(n))；

 

能夠看到，不論是讀請求，仍是寫請求，哈希類型的索引，都要比樹型的索引更快一些，那爲何，索引結構要設計成樹型呢？

畫外音：80%的同窗，面試都答不出來。

 

索引設計成樹形，和SQL的需求相關。

 

對於這樣一個單行查詢的SQL需求：

select * from t where name=」shenjian」;

確實是哈希索引更快，由於每次都只查詢一條記錄。

畫外音：因此，若是業務需求都是單行訪問，例如passport，確實可使用哈希索引。

 

可是對於排序查詢的SQL需求：

• 分組：group by

• 排序：order by

• 比較：<、>

• …

哈希型的索引，時間複雜度會退化爲O(n)，而樹型的「有序」特性，依然可以保持O(log(n)) 的高效率。

 

任何脫離需求的設計都是耍流氓。

 

多說一句，InnoDB並不支持哈希索引。

 

問題3. 數據庫索引爲何使用B+樹？

爲了保持知識體系的完整性，簡單介紹下幾種樹。

 

第一種：二叉搜索樹

二叉搜索樹，如上圖，是最爲你們所熟知的一種數據結構，就不展開介紹了，它爲何不適合用做數據庫索引？

(1)當數據量大的時候，樹的高度會比較高，數據量大的時候，查詢會比較慢；

(2)每一個節點只存儲一個記錄，可能致使一次查詢有不少次磁盤IO；

畫外音：這個樹常常出如今大學課本里，因此最爲你們所熟知。

 

第二種：B樹

B樹，如上圖，它的特色是：

(1)再也不是二叉搜索，而是m叉搜索；

(2)葉子節點，非葉子節點，都存儲數據；

(3)中序遍歷，能夠得到全部節點；

畫外音，實在不想介紹這個特性：非根節點包含的關鍵字個數j知足，(┌m/2┐)-1 <= j <= m-1，節點分裂時要知足這個條件。

 

B樹被做爲實現索引的數據結構被創造出來，是由於它可以完美的利用「局部性原理」。

 

什麼是局部性原理？

局部性原理的邏輯是這樣的：

(1)內存讀寫塊，磁盤讀寫慢，並且慢不少；

 

(2)磁盤預讀：磁盤讀寫並不是按需讀取，而是按頁預讀，一次會讀一頁的數據，每次加載更多的數據，若是將來要讀取的數據就在這一頁中，能夠避免將來的磁盤IO，提升效率；

畫外音：一般，一頁數據是4K。

 

(3)局部性原理：軟件設計要儘可能遵循「數據讀取集中」與「使用到一個數據，大機率會使用其附近的數據」，這樣磁盤預讀能充分提升磁盤IO；

 

B樹爲什麼適合作索引？

(1)因爲是m分叉的，高度可以大大下降；

(2)每一個節點能夠存儲j個記錄，若是將節點大小設置爲頁大小，例如4K，可以充分的利用預讀的特性，極大減小磁盤IO；

 

第三種：B+樹

B+樹，如上圖，還是m叉搜索樹，在B樹的基礎上，作了一些改進：

(1)非葉子節點再也不存儲數據，數據只存儲在同一層的葉子節點上；

畫外音：B+樹中根到每個節點的路徑長度同樣，而B樹不是這樣。

 

(2)葉子之間，增長了鏈表，獲取全部節點，再也不須要中序遍歷；

 

這些改進讓B+樹比B樹有更優的特性：

(1)範圍查找，定位min與max以後，中間葉子節點，就是結果集，不用中序回溯；

畫外音：範圍查詢在SQL中用得不少，這是B+樹比B樹最大的優點。

 

(2)葉子節點存儲實際記錄行，記錄行相對比較緊密的存儲，適合大數據量磁盤存儲；非葉子節點存儲記錄的PK，用於查詢加速，適合內存存儲；

 

(3)非葉子節點，不存儲實際記錄，而只存儲記錄的KEY的話，那麼在相同內存的狀況下，B+樹可以存儲更多索引；

 

最後，量化說下，爲何m叉的B+樹比二叉搜索樹的高度大大大大下降？

大概計算一下：

(1)局部性原理，將一個節點的大小設爲一頁，一頁4K，假設一個KEY有8字節，一個節點能夠存儲500個KEY，即j=500

(2)m叉樹，大概m/2<= j <=m，便可以差很少是1000叉樹

(3)那麼：

一層樹：1個節點，1*500個KEY，大小4K

二層樹：1000個節點，1000*500=50W個KEY，大小1000*4K=4M

三層樹：1000*1000個節點，1000*1000*500=5億個KEY，大小1000*1000*4K=4G

畫外音：額，幫忙看下有沒有算錯。

 

能夠看到，存儲大量的數據（5億），並不須要過高樹的深度（高度3），索引也不是太佔內存（4G）。

 

總結

• 數據庫索引用於加速查詢

• 雖然哈希索引是O(1)，樹索引是O(log(n))，但SQL有不少「有序」需求，故數據庫使用樹型索引

• InnoDB不支持哈希索引

• 數據預讀的思路是：磁盤讀寫並非按需讀取，而是按頁預讀，一次會讀一頁的數據，每次加載更多的數據，以便將來減小磁盤IO

• 局部性原理：軟件設計要儘可能遵循「數據讀取集中」與「使用到一個數據，大機率會使用其附近的數據」，這樣磁盤預讀能充分提升磁盤IO

• 數據庫的索引最經常使用B+樹：

(1)很適合磁盤存儲，可以充分利用局部性原理，磁盤預讀；

(2)很低的樹高度，可以存儲大量數據；

(3)索引自己佔用的內存很小；

(4)可以很好的支持單點查詢，範圍查詢，有序性查詢；