MySQL01-引擎索引與基礎數據結構

MySql引擎比較

  • 在介紹MySql索引以及底層數據結構以前想先對比一下MySql的幾種存儲引擎
功能/索引 MyISAM InnoDB MEMORY
索引類型 非聚簇索引 聚簇索引 Hash
存儲限制 256TB 64TB RAM
支持事務 No Yes No
支持表鎖 Yes Yes None
支持行鎖 No Yes None
支持全文索引 Yes Yes(5.6之後支持) No
支持樹索引 Yes Yes Yes
支持Hash索引 No No Yes
支持數據緩存 No Yes N/A
支持外鍵 No Yes No
適合操做類型 大量select 大量insert、delete、update 非持久化

基礎數據結構介紹

基礎數據類型介紹:
1. AVL樹(二叉平衡搜索樹,全部節點左右子樹高度差不超過1)
2. 紅黑樹(最深子樹高度不會超過最淺子樹高度的2倍)
3. B樹
4. B+樹
5. Hash
最好的演示網站:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

MySql數據結構的選擇

首先來分析一下幾種基礎數據類型html

1. Hash表的索引格式

image.png

Hash表的索引格式首先須要計算Hash值,而後用mod方法肯定值存儲的位置,若是該位置已經有值,那就是Hash衝突,須要在該值下面的鏈表尾添加數據

缺點:緩存

一、利用hash存儲的話須要將全部的數據文件添加到內存,比較耗費內存空間
二、若是全部的查詢都是等值查詢,那麼hash確實很快,可是在企業或者實際工做環境中範圍查找的數據更多,而不是等值查詢,所以hash就不太適合了

2. 二叉樹和紅黑樹的索引

二叉樹比較簡單,介紹一下紅黑樹特色數據結構

紅黑樹特色:
1. 每一個節點非紅即黑
二、根節點是黑色
三、每一個葉節點(葉節點即樹尾端NULL指針或NULL節點)都是黑的
四、如圖所示,若是一個節點是紅的,那麼它的兩個兒子都是黑的
五、對於任意節點而言,其到葉子節點樹NULL指針的每條路徑都包含相同數目的黑節點
六、每條路徑都包含相同的黑節點
七、紅黑樹確保沒有一條路徑會比其餘路徑長出兩倍

image.png

一、二叉樹每一個節點的左子樹上的值都小於該節點,右子樹的值都大於該節點,若是頻繁插入和刪除節點,最後二叉樹就會退化爲一個拍好序的鏈表,而影響查找
二、AVL嚴格平衡二叉樹,節點刪除和插入時都須要經過旋轉來保持二叉樹的平衡性,全部葉子節點的高度差不超過1,AVL保持了良好的查找特性,可是插入和刪除的旋轉操做複雜且耗時,因此AVL樹只適合大量查找,可是修改不頻繁的場景
三、紅黑樹是一種簡化後的二叉樹,它的要求沒有那麼嚴格,最深子樹高度不會超過最淺子樹高度的2倍

缺點:性能

不管是二叉樹仍是紅黑樹,都會由於樹的深度過深而形成io次數變多,影響數據讀取的效率

3. B樹索引格式

B樹特色:
一、全部鍵值分佈在整顆樹中
二、搜索有可能在非葉子結點結束,在關鍵字全集內作一次查找,性能逼近二分查找
三、每一個節點最多擁有m個子樹
四、根節點至少有2個子樹
五、分支節點至少擁有m/2顆子樹(除根節點和葉子節點外都是分支節點)
六、全部葉子節點都在同一層、每一個節點最多能夠有m-1個key,而且以升序排列

image.png

實例圖說明:
每一個節點佔用一個磁盤塊,一個節點上有兩個升序排序的關鍵字和三個指向子樹根節點的指針,指針存儲的是子節點所在磁盤塊的地址。兩個關鍵詞劃分紅的三個範圍域對應三個指針指向的子樹的數據的範圍域。以根節點爲例,關鍵字爲 16 和 34,P1 指針指向的子樹的數據範圍爲小於 16,P2 指針指向的子樹的數據範圍爲 16~34,P3 指針指向的子樹的數據範圍爲大於 34。 

查找關鍵字過程:
一、根據根節點找到磁盤塊 1,讀入內存。【磁盤 I/O 操做第 1 次】
二、比較關鍵字 28 在區間(16,34),找到磁盤塊 1 的指針 P2。
三、根據 P2 指針找到磁盤塊 3,讀入內存。【磁盤 I/O 操做第 2 次】
四、比較關鍵字 28 在區間(25,31),找到磁盤塊 3 的指針 P2。
五、根據 P2 指針找到磁盤塊 8,讀入內存。【磁盤 I/O 操做第 3 次】
六、在磁盤塊 8 中的關鍵字列表中找到關鍵字 28。 優化

缺點:網站

一、每一個節點都有key,同時也包含data,而每一個頁存儲空間是有限的,若是data比較大的話會致使每一個節點存儲的key數量變小
二、當存儲的數據量很大的時候會致使深度較大,增大查詢時磁盤io次數,進而影響查詢性能

4. MySql索引數據結構--B+Tree

B+Tree是在BTree的基礎之上作的一種優化,變化以下:
一、B+Tree每一個Key右邊的子節點是大於等於該節點的值,這樣就能夠把Data都存在葉子節點
二、B+Tree每一個節點能夠包含更多的節點,這個作的緣由有兩個,第一個緣由是爲了下降樹的高度,第二個緣由是將
數據範圍變爲多個區間,區間越多,數據檢索越快
三、非葉子節點存儲key,葉子節點存儲key和數據
四、葉子節點兩兩指針相互鏈接(符合磁盤的預讀特性),順序查詢性能更高

image.png
注意:spa

在B+Tree上有兩個頭指針,一個指向根節點,另外一個指向關鍵字最小的葉子節點,並且全部葉子節點(即數據節點)之間是一種鏈式環結構。所以能夠對 B+Tree 進行兩種查找運算:一種是對於主鍵的範圍查找和分頁查找,另外一種是從根節點開始,進行隨機查找。

InnoDB的B+Tree索引3d

一、InnoDB是經過B+Tree結構對主鍵建立索引,而後葉子節點中存儲記錄,若是沒有主鍵,那麼會選擇惟一鍵,若是沒有惟一鍵,那麼會生成一個6位的row_id來做爲主鍵( 主鍵索引不容許爲空,惟一索引容許爲空
二、若是建立索引的鍵是其餘字段,那麼在葉子節點中存儲的是該記錄的主鍵,而後再經過主鍵索引找到對應的記錄,叫作回表

索引中的常見技術名詞

1. 回表

對於普通列的索引,其B+樹的葉子節點存儲的不是整行的值,而是主鍵的值,先找到普通索引值,而後再經過主鍵的B+樹查找到整行的值,這個過程稱爲回表

2. 覆蓋索引

若是查詢所須要的值就只有主鍵值,那麼經過普通列索引搜索B+樹最後獲得的就是所需值,不須要回表,這個就稱爲覆蓋索引

3. 最左匹配

where條件中的字段值必須按照索引順序,不能跳過某個值
例如:name age是索引
select * from emp where name=?(索引生效)
select * from emp where age=?(索引不生效)

4. 索引下推

索引在最初查詢時已經通過篩選,不須要在Server再作計算
相關文章
相關標籤/搜索