mysql 索引原理—索引的資料結構
MySQL為什麼選擇B+Tree索引
快速查詢的資料型別大致有hash表,二叉樹,平衡二叉樹,B-Tree,B+Tree。
hash表
hash表查詢方式是基於資料的Key的hashcode得到陣列下標,如果儲存的為連結串列,則遍歷連結串列進行value比較;如果儲存的為紅黑樹,則用二分查詢法。
所以hash表在數量量不大,並且進行等值查詢的時候效率較高,但不能範圍查詢。
二叉樹
二叉樹資料的組織方式是左小右大:即當前存入的資料比當前節點的關鍵字小,遞迴左子節點;若當前存入資料比當前節點的關鍵字大.遞迴右子節點。
如果我們用自增序列作為主鍵建立索引,則會形成
所以就衍生平衡二叉樹
平衡二叉樹
平衡二叉樹為了保證樹的平衡性,在資料的插入和刪除的過程中,會進行一系列的計算.將樹進行左/右旋轉滿足樹的平衡性
但是平衡二叉樹在數量大的時候樹高會很高,再查詢末端節點會遞迴多次才能找到資料,並且每個階段只存一個數據會有多次的IO操作才能找到資料。
作業系統與磁碟的互動是採用頁為基本的交換單位.一頁資料大小是4KB,再加上作業系統的預讀能力[空間區域性性原理],一次磁碟的IO互動將會帶來N頁的資料返回,而一個節點只要一個數據,完全沒法填滿,一次IO只能有少量的有效資料
B-Tree
B-Tree的優勢
1.將磁碟IO的低效操作通過記憶體中資料比較進行替換
在二叉樹中,我們一次只能載入一個關鍵字進行匹配.但是在B-樹,我們一次可以載入N個關鍵字,若我們將磁碟塊(節點)的空間大小固定(MySQL中定義為16KB).磁碟塊能儲存的關鍵字個數就會與單個關鍵字內容佔用的空間相關.基於預讀和作業系統磁碟互動特性.我們磁碟IO一次載入的內容正好都是我們需要比對的內容.講內容的多次IO載入轉換成在記憶體中進行資料的比較
2.合理的降低樹的高度,減少IO的次數
假如一個節點則可以放入1000個有效資料,二層則有10011000,三層就要(1001
B+Tree
B+樹是基於B-樹結構的加強版樹形結構.
B-樹擁有的特性B+樹都擁有.
B+樹的資料匹對規則採用閉合區間的方式
B+樹的非葉子節點上不儲存關鍵字對應的資料區
B+樹的葉子節點上儲存資料區
在葉子節點上的資料產生形成首尾相連的鏈式結構帶來更高效的資料排序
基於以上你的結構特點B+樹相較於B-樹又哪些優勢呢?
B-樹擁有的特性,B+樹都擁有
B+樹擁有更強勁的磁碟IO能力.
在非葉子節點不存在資料區,將大大降低節點的空間佔用.能儲存更多的關鍵字.一次磁碟IO帶回來的有效資料將更多更精準
B+樹擁有更好的資料排序能力
這是B+樹的天然優勢,在最末尾的葉子節點這一層天然即有序的鏈式結構
基於B+樹的掃表能力更強
在B+樹的資料結構中,若需要掃表,只需要掃描最末尾的葉子節點即可.
基於B+樹結構的索引的查詢,更趨於穩定
在B-樹結構中,我們發現,我們的關鍵字在某一個節點進行匹對成功就完成資料區內容的返回.但是在B+樹結構中,我們採用的是閉合區間的比對方式即資料的最終載入一定會在葉子節點上.在B-樹結構中,有可能針對一張表的查詢,有些資料需要3次IO.有些只需要1次IO.前後的查詢效率跌跌宕宕不穩定.但是在B+樹結構中一定恆定的IO次數,帶來更穩定的查詢效率.基於以上的對比和總結,MySQL最終選擇了B+Tree作為了索引的資料結構