《MySQL面試小抄》索引考點一面總結

《MySQL面試小抄》索引考點一面總結

我是肥哥，一名不專業的面試官！

我是囧囧，一名積極找工做的小菜鳥，囧囧表示：面試最怕的就是面試官問的知識點太籠統，本身沒法快速定位到關鍵問題點！！！

---

本期主要面試考點

面試官考點之談談你對索引的理解？

面試官考點之解釋一下計算機層面索引快的緣由？

面試官考點之爲何不使用哈希結構做爲索引結構？

面試官考點之爲何不使用二叉樹做爲索引結構？

面試官考點之爲何不使用B-Tree，而是B+Tree？

面試官考點之索引是加速查詢，那麼是否應該給表儘量創建多的索引列？

---

---

面試官考點之談談你對索引的理解？

談到索引，最早聯想到的大概就是字典目錄，根據MySQL官方定義，索引是用來幫助MySQL高效獲取數據的一種數據結構。

本質上：索引是一種有序的快速查找的數據結構，用來快速高效的查找數據。

簡單來講，能夠類比字典目錄，火車車次表。

面試官考點之解釋一下計算機層面索引快的緣由？

計算機從磁盤獲取數據，加載到內存期間，通常都要經歷3個常規的耗時過程：

一、尋道（時間）：肯定要讀的數據在哪一個磁道耗費的時間
二、旋轉延遲（時間）：肯定要讀的數據在磁道上的哪一個扇區耗費的時間
三、數據傳輸（時間）：數據加載到內存耗費的時間

每次加載數據，咱們稱其爲一次磁盤IO，每一次IO操做耗費時間 = 尋道 + 旋轉延遲 + 數據傳輸（時間短暫，能夠忽略不計）。

事實上實際加載數據到內存的時間很是短暫，一次IO操做主要的耗時來自尋道和旋轉延遲。

整體來講，通常一次IO操做，耗時大概只有幾ms。假如是4ms，雖然看起來很短暫，可是數據庫百萬級別的數據加載一遍，就須要4000s，對於一個系統來講，簡直是毀滅級別的。

咱們須要的就是減小磁盤IO的次數，這也是使用索引的意義所在！！！索引可以保證在億級別的數據，只須要2~4次磁盤IO，這無疑是個福音！

面試官考點之爲何不使用哈希結構做爲索引結構？

通常正常的業務場景中，一般查詢多數是範圍查詢 相似：

select id, name, age from sys_user where age between 18 and 28;

哈希結構做爲索引，那麼存儲引擎就會爲每一行表記錄計算出哈希值，哈希索引存儲的就是HASH碼；

HASH碼直接隨機生成，並無規律

沒有規律的HASH碼，致使數據隨機分佈存儲，這就致使即便是兩個很相近的行記錄，極大可能也會被分配到不一樣的桶（磁盤塊）中。

最壞的狀況下每查找一條記錄，都要進行一次磁盤IO （可怕）。

優勢，哈希結構這樣key-val 鍵值對的形式對於精確查找很是敏感，對全值匹配很友好，因此單條記錄查詢效率很是高，時間複雜度爲 1，可是咱們平常業務來講，最經常使用的仍是範圍搜索，因此不哈希結構適合。

記住一點便可：Hash索引適合精確查找，全值匹配，不適合範圍查找。

MySQL目前有Memory引擎和NDB引擎支持Hash索引。

面試官考點之爲何不使用二叉樹做爲索引結構？

首先觀察一下二叉樹結構

二叉樹最多有兩個子節點，這種結構致使樹的高度會很高，增長IO次數，特殊狀況下可能化爲鏈表結構，至關於全表掃描，全量磁盤IO。

假設二叉樹結構做爲索引，理想狀況下是一顆徹底二叉樹，那麼具備n個節點的徹底二叉樹深度爲log2x+1

（其中x表示不大於n的最大整數）

若是一個數據在二叉樹結構的100層，那麼爲了查找到此數據，須要進行100次磁盤IO。更糟糕狀況下，二叉樹會退化成鏈表結構，既，斜二叉樹。

相似的平衡二叉樹，高度也很高。

面試官考點之爲何不使用B-Tree，而是B+Tree？

既然二叉樹結構樹高度很高，致使查詢時磁盤IO增長，那B-Tree 呢？B-Tree能夠存儲更多的數據，高度更低，爲何不選擇？而是B+Tree？

B-Tree是多路平衡搜索樹，相比二叉樹結構，能夠極大的優化磁盤IO次數，可是B-Tree每一個節點中不只包含數據的key（索引值），還有data（整行記錄），使用B-Tree結構，優勢是找到索引就表明找到了數據記錄。

既然如此爲何不使用B-Tree結構？仍是老問題，磁盤IO數！！！

咱們知道MySQL讀取數據是以頁爲單位（磁盤塊），每頁（或者說每一個磁盤塊）的存儲空間是有限的

若是data 很大，將會致使每頁存儲的索引數量很小

因此數據表存儲的數據量很大的時候一樣會致使 B-Tree的深度很大，增大查詢時的磁盤I/O次數，進而影響查詢效率。

再說到B+Tree，B+Tree是對B-Tree 的一種優化結構，使其更適合實現外存儲索引結構

一、非葉子節點只存儲鍵值信息(索引信息)

二、全部的數據記錄都按照鍵值大小順序存放在同一層的葉子節點上

好處：B+Tree的非葉子節點只存儲鍵值信息，那麼每一頁能存儲更多的索引，樹的高度被壓縮到很低，磁盤IO次數更小，通常狀況下2~4次IO，便可查詢到想要的記錄。

並且由於表數據都是順序存儲在B+Tree結構的葉子節點，因此對於範圍查找很友好，效率高！

面試官考點之索引是加速查詢，那麼是否應該給表儘量創建多的索引列？

雖然索引的優點是加快查詢效率，減小磁盤IO次數，可是盲目建立過多索引，大大增長了維護索引的時間成本和空間成本。

首先說一下索引的好處

一、減小IO次數，提升-檢索效率

二、下降數據排序成本，能夠減小CPU消耗

時間成本

由於索引是有序的快速查找結構，要維護索引的這個快速查找且有序特性，須要不斷的進行調整，而調整就須要時間成本。

建立索引和維護索引要耗費時間，當對錶中的數據進行增長、刪除和修改的時候，索引也要動態地維護，這樣就下降了數據的維護速度。

並且這種時間成本隨着數據量的增長而增長！

空間成本

其次，每個索引都是一棵B+Tree，保存索引和指向實體表的引用，須要佔據空間。

若是創建的是聚簇索引，數據和主鍵都保存在索引文件中，則須要更大的空間成本。

敬請期待囧囧小白索引二面內容！

更多精彩內容，歡迎關注微信公衆號：囧麼肥事 （或搜索：jiongmefeishi）

閱讀原文：《MySQL面試小抄》索引考點一面總結