MySQL索引底層實現

索引的本質

MySQL官方對於索引的定義爲：索引是幫助MySQL高效獲取數據的數據結構。便可以理解爲：索引是數據結構。

 

咱們知道，數據庫查詢是數據庫最主要的功能之一，咱們都但願查詢數據的速度儘量的快，所以數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法固然是順序查找，固然這種時間複雜度爲O(n)的算法在數據量很大時顯然是糟糕的，因而有了二分查找、二叉樹查找等。可是二分查找要求被檢索數據有序，而二叉樹查找只能應用於二叉查找樹，可是數據自己的組織結構不可能徹底知足各類數據結構。因此，在數據以外，數據庫系統還維護者知足特定查找算法的數據結構，這些數據結構以某種方式引用數據，這樣就能夠在這些數據結構上實現高級查找算法。這種數據結構，就是索引。

 

B-Tree和B+Tree

目前大部分數據庫系統及文件系統都採用B-Tree和B+Tree做爲索引結構。

 

索引

索引的目的：提升查詢效率

原理：經過不斷的縮小想要得到數據的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是咱們老是經過同一種查找方式來鎖定數據。

數據結構：B+樹

圖解B+樹與查找過程：

 

如上圖，是一顆b+樹，關於b+樹的定義能夠參見B+樹，這裏只說一些重點，淺藍色的塊咱們稱之爲一個磁盤塊，能夠看到每一個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），如磁盤塊1包含數據項17和35，包含指針P一、P二、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。真實的數據存在於葉子節點即三、五、九、十、1三、1五、2八、2九、3六、60、7五、7九、90、99。非葉子節點只不存儲真實的數據，只存儲指引搜索方向的數據項，如1七、35並不真實存在於數據表中。

 

b+樹的查找過程

如圖所示，若是要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找肯定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間由於很是短（相比磁盤的IO）能夠忽略不計，經過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，經過指針加載磁盤塊8到內存，發生第三次IO，同時內存中作二分查找找到29，結束查詢，總計三次IO。真實的狀況是，3層的b+樹能夠表示上百萬的數據，若是上百萬的數據查找只須要三次IO，性能提升將是巨大的，若是沒有索引，每一個數據項都要發生一次IO，那麼總共須要百萬次的IO，顯然成本很是很是高。

 

b+樹性質

經過上面的分析，咱們知道IO次數取決於b+數的高度h，假設當前數據表的數據爲N，每一個磁盤塊的數據項的數量是m，則有h=㏒(m+1)N，當數據量N必定的狀況下，m越大，h越小；而m = 磁盤塊的大小 / 數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的，若是數據項佔的空間越小，數據項的數量越多，樹的高度越低。這就是爲何每一個數據項，即索引字段要儘可能的小，好比int佔4字節，要比bigint8字節少一半。這也是爲何b+樹要求把真實的數據放到葉子節點而不是內層節點，一旦放到內層節點，磁盤塊的數據項會大幅度降低，致使樹增高。當數據項等於1時將會退化成線性表。