MySQL索引原理，一篇從頭至尾講清楚

索引，可能讓好不少人望而生畏，畢竟每次面試時候 MySQL 的索引必定是必問內容，哪怕先撇開面試，就在日常的開發中，對於 SQL 的優化也而是重中之重。

能夠絕不誇張的說，系統中 SQL 的好壞，是能直接決定你係統的快慢的。可是在優化以前你們是否想過一個問題？那就是：咱們優化的原則是什麼？優化SQL的理論基礎是什麼？

雖說實踐出真知，可是我更相信理論是支撐實踐的基礎，由於咱們不可能毫無目的的去盲目的實踐，由於這樣每每事倍功半。

因此說了這麼多隻想告訴你們，在真正的開始索引優化以前，咱們須要完全搞明白索引的原理。這樣再談優化你將以爲更絲滑~

一、索引的本質

索引的本質是一種排好序的數據結構。這個我相信其實你們並不陌生，由於談到索引不少人天然而然的就會聯想到字典中的目錄。

沒錯，這樣的類比是很形象的，可是若是再往深處說，恐怕不少小夥伴就有點張口結舌了，那既然你已經知道了索引的本質，那麼您就已經有了看這篇文章的基礎，相信讀文本文的你，必定會對索引的原理有一個全新的瞭解。

二、索引的分類

在數據庫中，索引是分不少種類的（千萬不要狹隘的認爲索引只有 B+ 樹，那是由於咱們平時使用的基本都是 MySQL）。而不一樣的種類很顯然是爲了應付不一樣的場合，那索引到底有那些種類呢？下面就讓咱們來大體的瞭解下。

2.一、Hash 索引

Hash 索引是比較常見的一種索引，他的單條記錄查詢的效率很高，時間複雜度爲1。可是，Hash索引並非最經常使用的數據庫索引類型，尤爲是咱們經常使用的Mysql Innodb引擎就是不支持hash索引的。主要有如下緣由：

• Hash索引適合精確查找，可是範圍查找不適合
  • 由於存儲引擎都會爲每一行計算一個hash碼，hash碼都是比較小的，而且不一樣鍵值行的hash碼一般是不同的，hash索引中存儲的就是Hash碼，hash 碼彼此之間是沒有規律的，且 Hash 操做並不能保證順序性，因此值相近的兩個數據，Hash值相差很遠，被分到不一樣的桶中。這就是爲何hash索引只能進行全職匹配的查詢，由於只有這樣，hash碼纔可以匹配到數據。

對於 hash 索引，小夥伴們只須要了解到這裏就能夠了。

2.二、二叉樹

另外，常見的索引使用的數據結構是樹結構，首先咱們來介紹下最經典的二叉樹。

先來介紹下二叉樹的特色：

• 1. 二叉樹的時間複雜度爲 O(n)
• 1. 一個節點只能有兩個子節點。即度不超過2
• 1. 左子節點 小於 本節點，右子節點 大於 本節點

首先來看一下二叉樹的樣子

可是在極端狀況下會出現鏈化的狀況，即節點一直在某一邊增長。以下圖

二叉樹中，有一種特殊的結構——平衡二叉樹，平衡二叉樹的特色：

• 1. 根節點會隨着數據的改變而變動
• 1. 數據量越多，遍歷次數越多，IO次數就越多，就越慢（磁盤的IO由樹高決定）

2.四、B樹（二三樹）

瞭解了二叉樹以後，能夠進一步談一下什麼是B樹了。B 樹大概是這樣子的：

從B樹的結構圖中能夠看到每一個節點中不只包含數據的 key 值，還有 data 值。

而每頁的存儲空間是有限的，若是 data 比較大，會致使每一個節點的 key 存儲的較少，當數據量較大的時候，一樣會致使B樹很深，從而增長了磁盤 IO 的次數，進而影響查詢效率。

好了，說到這裏，常見的索引的種類也說完了，上面的內容僅僅是做爲一個鋪墊，下面咱們正式開始 MySQL 的 B+ 樹。

2.五、B+樹

MySQL 中最經常使用的索引的數據結構是 B+ 樹，他有如下特色：

1. 在 B+ 樹中，全部數據記錄節點都是按照鍵值的大小存放在同一層的葉子節點上，而非葉子結點只存儲key的信息，這樣能夠大大減小每一個節點的存儲的key的數量，下降B+ 樹的高度
2. B+ 樹葉子節點的關鍵字從小到大有序排列，左邊結尾數據都會保存右邊節點開始數據的指針。
3. B+ 樹的層級更少：相較於 B 樹 B+ 每一個非葉子節點存儲的關鍵字數更多，樹的層級更少因此查詢數據更快
4. B+ 樹查詢速度更穩定：B+ 全部關鍵字數據地址都存在葉子節點上，因此每次查找的次數都相同因此查詢速度要比B樹更穩定;
5. B+ 樹自然具有排序功能：B+ 樹全部的葉子節點數據構成了一個有序鏈表，在查詢大小區間的數據時候更方便，數據緊密性很高，緩存的命中率也會比B樹高。
6. B+ 樹全節點遍歷更快：B+ 樹遍歷整棵樹只須要遍歷全部的葉子節點便可，，而不須要像 B 樹同樣須要對每一層進行遍歷，這有利於數據庫作全表掃描。

好了說了這麼多的 B+ 樹的特色，咱們來張圖看看 B+ 樹到底長什麼樣子（若是看不懂，也沒有關係，下文會一步一步解釋說明的）

上面的數據頁就是實際存放數據頁的地方，且數據頁之間是經過雙向鏈表進行鏈接的，好了到這裏咱們就將各個索引的類型快速瞭解了下，下面咱們就開始正式B+樹的分析。

三、主鍵目錄

咱們將上圖中的數據頁拿出來再細化下，就成了下面的這張圖

咱們都知道 MySQL 在存儲數據的時候是以數據頁爲最小單位的，且數據在數據頁中的存儲是連續的，數據頁中的數據是按照主鍵排序的（沒有主鍵是由 MySQL本身維護的 ROW_ID 來排序的），數據頁和數據頁之間是經過雙向鏈表來關聯的，數據與數據時間是經過單向鏈表來關聯的。

也就是說有一個在每一個數據頁中，他必然就有一個最小的主鍵，而後每一個數據頁的頁號和最小的主鍵會組成一個主鍵目錄（就像上圖中的左邊部分），假設如今要查找主鍵爲 2 的數據，經過二分查找法最後肯定下主鍵爲 2 的記錄在數據頁 1 中，此時就會定位到數據頁 1 接着再去定位主鍵爲 2 的記錄，咱們先知道大體的流程，細節先不要深究，先從宏觀看結構原理，再到微觀看實現原理。

剛剛上面是說的其實能夠理解爲是主鍵索引，主鍵索引也是最簡單的最基礎的索引。這個時候你們應該知道爲何你創建了主鍵查詢就能變快了吧？

四、索引頁

可是如今假設有不少不少的是數據頁，那是否是對應的主鍵目錄會很大很大呢？

那假設有1000萬條記錄、5000萬條記錄呢？是否是就算是二分法查找，其效率也依舊是很低的，因此爲了解決這種問題 MySQL 又設計出了一種新的存儲結構—索引頁。例若有下面這樣狀況，

假設上面的主鍵目錄中的記錄是很是很是多的，此時上面的結構是演變成這樣子的，MySQL 會將裏面的記錄拆分到不一樣的索引頁中，也就是下面這樣子的

索引頁中記錄的是每頁數據頁的頁號和該數據頁中最小的主鍵的記錄，也就是說最小主鍵和數據頁號不是單純的維護在主鍵目錄中了，而是演變成了索引頁，索引頁和數據頁相似，一張不夠存就分裂到下一張。

假如如今要查找 id=20 的這條記錄，咦？那我應該到哪一個索引頁中查找該條記錄呢？因此這個時候確定是須要去維護索引頁的。

沒錯，MySQL 也是這麼設計的，也就是說 MySQL 同時也設計出了用於維護索引頁的數據結構，其實也還叫索引頁，只不過他們是在不一樣的層級，相似下面這樣子的：

也就是說維護索引頁的索引頁是在真正存儲記錄和數據頁的索引頁的上一層，如今若是你想查找 id=20 的這條記錄，那就是從最上層的索引頁開始查找，經過二分法查找，很快就可以定位到 id=20 s這條記錄是在索引頁 2 上，而後到就索引頁 2 上面查找，接着就是和以前同樣了（注意，索引頁中的記錄也是經過單向鏈表鏈接的），根據各個最小的主鍵可以定位到 id=20 是在數據頁5上，假設數據頁5是這樣子的

那這個時候你是否是可以想明白數據是怎麼定位的了呢？

五、索引頁的分層

好，既然你已經知道到索引頁太多會往上一層擴散，那如今假設上一層的索引頁記錄也太多了，那該怎麼辦？很簡單，繼續分裂，再往上一層繼續，不廢話，我來畫圖幫助你們理解

我看明白了，你看明白了嗎？咱們來模擬一個查找的過程，假設你要查找 37 這條記錄，說實話我根本不知道這條記錄在哪裏。好，如今咱們就來模擬 MySQL 的查找過程，首先從最頂層的索引頁開始查找，由於 id=37，所以定位到了索引頁16，而後到索引頁 16 中繼續查找，此時一樣可以定位到 id=37 在索引頁 3 中，而後繼續查找，最終可以定位到數據實在數據頁 8 中，假設數據頁 8 是這樣子的

是否是很完美？若是非要我把上面的圖畫完整，那....小弟責無旁貸（圖太大了，索引頁中數據的鏈表結構就不畫出來了）

這個時候機智的你是否是已經發現了什麼小祕密？他是否是很像一顆二叉樹？實際上這就是一顆 B+ 樹的結構，這也是數據在磁盤中真正存儲的物理結構。B+樹的特性是什麼呢？B+樹，也是二叉搜索樹的一種，可是他的數據僅僅存儲在葉子節點（在這裏就是數據頁），像這種索引頁+數據頁組成的組成的B+樹就是聚簇索引(這句話很重要)。

聚簇索引是 MySQL 基於主鍵索引結構建立的

六、非主鍵索引

可是如今問題又來了，既然這裏強調的是主鍵索引，那咱們平時開發中除了主鍵索引其餘的索引也用的很多，這時候該怎麼辦？假設你如今對name、age創建索引。如今回顧下主鍵索引，是否是在插入數據的時候基於主鍵的順序去維護一個 B+ 樹的？

而實際上非主鍵索引其原理是同樣的，MySQL 都是去維護一顆 B+ 樹，說白了，你創建多少個索引，MySQL 就會幫你維護多少的B+樹（這下是否是也忽然想明白了爲何索引不能創建太多了？之前就知道不能創建太多索引，由於索引也會佔用空間，實際上這就是根本緣由）

假如如今真的對name+age創建索引，那此時是存放的呢？此時 MySQL 根據會 name+age 維護一個單獨的 B+ 樹結構，數據依舊是存放在數據頁中的，只不過是原來數據中的每條記錄寫的是 id=xx，如今寫的是name=xx，age=xx，id=xx，無論怎麼樣，主鍵確定會存放的，先來張圖壓壓驚

在插入數據的時候，MySQL 首先會根據 name 進行排序，若是 name 同樣，就根據聯合索引中的 age 去排序，若是還同樣，那麼就會根據 主鍵 字段去排序。插入的原理就是這樣子的。

此時每一個數據頁中的記錄存放的實際是索引字段和主鍵字段，而其餘字段是不存的（爲何不存放？同樣的數據處處存放很浪費空間的，也不必，因此纔會有下面的索引優化），至於查找，原理和過程跟聚簇索引同樣，這裏就再也不贅述，可是，下面說的內容倒是相當重要的：假設如今執行這樣的SQL：

SELECT name FROM student WHERE name='wx'
複製代碼

那麼此時的查詢是完美的，使用到了索引且不須要回表

7.回表

是這樣子的，如今要根據 name 查找到該條記錄，且查詢的字段（即 select 後面的查詢字段）也僅僅有 name（只要是在 name,age,id 這三個字段中均可以）這個時候是可以直接獲取到最終的記錄的

換句話說，由於聯合索引中的記錄也僅僅有 name，age，id，因此在查詢的若是也僅僅查詢這三個字段，那麼在該B+樹中就可以查詢到想要的結果了。

那如今假設查詢的 SQL 是這樣子的（咱們假設 student 中還有除了name，age，id 其餘的字段 ）

SELECT * FROM student WHERE name='wx'
複製代碼

那這下子就完蛋了，由於你如今雖然根據 name 很快的定位到了該條記錄，可是由於 name+age 不是聚簇索引，此時的 B+ 樹的數據頁中存放的僅僅是本身關聯的索引和主鍵索引字段，並不會存其餘的字段，因此這個時候其餘的屬性值是獲取不到的，這時候該怎麼辦？

這種狀況下，MySQL 就須要進行回表查詢了。此時 MySQL 就會根據定位到的某條記錄中的 id 再次進行聚簇索引查找，也就是說會根據 id 去維護 id 的那麼 B+ 樹中查找。由於聚簇索引中數據頁記錄的是一條記錄的完整的記錄，這個過程就叫回表。

再強調下回表的含義：根據非主鍵索引查詢到的結果並無查找的字段值，此時就須要再次根據主鍵從聚簇索引的根節點開始查找，這樣再次查找到的記錄纔是完成的。

最後，讓我一塊兒看下 MySQL 對於非主鍵索引的維護過程：

對於非主鍵索引（通常都是聯合索引），在維護 B+ 樹的時候，會根據聯合索引的字段依次去判斷，假設聯合索引爲：name + address + age，那麼 MySQL 在維護該索引的 B+ 樹的時候，首先會根據 name 進行排序，name 相同的話會根據第二個 address 排序，若是 address 也同樣，那麼就會根據 age 去排序，若是 age 也同樣，那麼就會根據主鍵字段值去排序，且對於非主鍵索引，MySQL 在維護 B+ 樹的時候，僅僅是維護索引字段和主鍵字段。