個人博客請訪問 http://www.x0100.top
Mysql 作爲互聯網中非常熱門的數據庫，其底層的存儲引擎和數據檢索引擎的設計非常重要，尤其是 Mysql 數據的存儲形式以及索引的設計，決定了 Mysql 整體的數據檢索性能。
我們知道，索引的作用是做數據的快速檢索，而快速檢索的實現的本質是數據結構。通過不同數據結構的選擇，實現各種數據快速檢索。在數據庫中，高效的查找算法是非常重要的，因爲數據庫中存儲了大量數據，一個高效的索引能節省巨大的時間。比如下面這個數據表，如果 Mysql 沒有實現索引算法，那麼查找 id=7 這個數據，那麼只能採取暴力順序遍歷查找，找到 id=7 這個數據需要比較 7 次，如果這個表存儲的是 1000W 個數據，查找 id=1000W 這個數據那就要比較 1000W 次，這種速度是不能接受的。
Mysql 索引底層數據結構選型
1. 哈希表（Hash）
哈希表是做數據快速檢索的有效利器。
哈希算法：也叫散列算法，就是把任意值(key)通過哈希函數變換爲固定長度的 key 地址，通過這個地址進行具體數據的數據結構。
考慮這個數據庫表 user，表中一共有 7 個數據，我們需要檢索 id=7 的數據，SQL 語法是：
select * from user where id=7;
哈希算法首先計算存儲 id=7 的數據的物理地址 addr=hash(7)=4231，而 4231 映射的物理地址是 0x77，0x77 就是 id=7 存儲的額數據的物理地址，通過該獨立地址可以找到對應 user_name='g'這個數據。這就是哈希算法快速檢索數據的計算過程。
但是哈希算法有個數據碰撞的問題，也就是哈希函數可能對不同的 key 會計算出同一個結果，比如 hash(7)可能跟 hash(199)計算出來的結果一樣，也就是不同的 key 映射到同一個結果了，這就是碰撞問題。解決碰撞問題的一個常見處理方式就是鏈地址法，即用鏈表把碰撞的數據接連起來。計算哈希值之後，還需要檢查該哈希值是否存在碰撞數據鏈表，有則一直遍歷到鏈表尾，直達找到真正的 key 對應的數據爲止。
從算法時間複雜度分析來看，哈希算法時間複雜度爲 O（1），檢索速度非常快。比如查找 id=7 的數據，哈希索引只需要計算一次就可以獲取到對應的數據，檢索速度非常快。但是 Mysql 並沒有採取哈希作爲其底層算法，這是爲什麼呢？
因爲考慮到數據檢索有一個常用手段就是範圍查找，比如以下這個 SQL 語句：
select * from user where id >3;
針對以上這個語句，我們希望做的是找出 id>3 的數據，這是很典型的範圍查找。如果使用哈希算法實現的索引，範圍查找怎麼做呢？一個簡單的思路就是一次把所有數據找出來加載到內存，然後再在內存裏篩選篩選目標範圍內的數據。但是這個範圍查找的方法也太笨重了，沒有一點效率而言。
所以，使用哈希算法實現的索引雖然可以做到快速檢索數據，但是沒辦法做數據高效範圍查找，因此哈希索引是不適合作爲 Mysql 的底層索引的數據結構。
2. 二叉查找樹(BST)
二叉查找樹是一種支持數據快速查找的數據結構，如圖下所示:
答案是可以的。觀察上面的圖，二叉樹的葉子節點都是按序排列的，從左到右依次升序排列，如果我們需要找 id>5 的數據，那我們取出節點爲 6 的節點以及其右子樹就可以了，範圍查找也算是比較容易實現。
但是普通的二叉查找樹有個致命缺點：極端情況下會退化爲線性鏈表，二分查找也會退化爲遍歷查找，時間複雜退化爲 O（N），檢索性能急劇下降。比如以下這個情況，二叉樹已經極度不平衡了，已經退化爲鏈表了，檢索速度大大降低。此時檢索 id=7 的數據的所需要計算的次數已經變爲 7 了。
3. AVL 樹和紅黑樹
二叉查找樹存在不平衡問題，因此學者提出通過樹節點的自動旋轉和調整，讓二叉樹始終保持基本平衡的狀態，就能保持二叉查找樹的最佳查找性能了。基於這種思路的自調整平衡狀態的二叉樹有 AVL 樹和紅黑樹。
首先簡單介紹紅黑樹，這是一顆會自動調整樹形態的樹結構，比如當二叉樹處於一個不平衡狀態時，紅黑樹就會自動左旋右旋節點以及節點變色，調整樹的形態，使其保持基本的平衡狀態（時間複雜度爲 O（logn）），也就保證了查找效率不會明顯減低。比如從 1 到 7 升序插入數據節點，如果是普通的二叉查找樹則會退化成鏈表，但是紅黑樹則會不斷調整樹的形態，使其保持基本平衡狀態，如下圖所示。下面這個紅黑樹下查找 id=7 的所要比較的節點數爲 4，依然保持二叉樹不錯的查找效率。
紅黑樹擁有不錯的平均查找效率，也不存在極端的 O(n)情況，那紅黑樹作爲 Mysql 底層索引實現是否可以呢？其實紅黑樹也存在一些問題，觀察下面這個例子。
紅黑樹順序插入 1~7 個節點，查找 id=7 時需要計算的節點數爲 4。
AVL 樹順序插入 1~7 個節點，查找 id=7 所要比較節點的次數爲 3。
總結一下 AVL 樹的優點：
-
不錯的查找性能（O（logn）），不存在極端的低效查找的情況。
-
可以實現範圍查找、數據排序。
看起來 AVL 樹作爲數據查找的數據結構確實很不錯，但是 AVL 樹並不適合做 Mysql 數據庫的索引數據結構，因爲考慮一下這個問題：
數據庫查詢數據的瓶頸在於磁盤 IO，如果使用的是 AVL 樹，我們每一個樹節點只存儲了一個數據，我們一次磁盤 IO 只能取出來一個節點上的數據加載到內存裏，那比如查詢 id=7 這個數據我們就要進行磁盤 IO 三次，這是多麼消耗時間的。所以我們設計數據庫索引時需要首先考慮怎麼儘可能減少磁盤 IO 的次數。
磁盤 IO 有個有個特點，就是從磁盤讀取 1B 數據和 1KB 數據所消耗的時間是基本一樣的，我們就可以根據這個思路，我們可以在一個樹節點上儘可能多地存儲數據，一次磁盤 IO 就多加載點數據到內存，這就是 B 樹，B+樹的的設計原理了。
4. B 樹
下面這個 B 樹，每個節點限制最多存儲兩個 key，一個節點如果超過兩個 key 就會自動分裂。比如下面這個存儲了 7 個數據 B 樹，只需要查詢兩個節點就可以知道 id=7 這數據的具體位置，也就是兩次磁盤 IO 就可以查詢到指定數據，優於 AVL 樹。
當我們把單個節點限制的 key 個數設置爲 6 之後，一個存儲了 7 個數據的 B 樹，查詢 id=7 這個數據所要進行的磁盤 IO 爲 2 次。
-
優秀檢索速度，時間複雜度：B 樹的查找性能等於 O（h*logn），其中 h 爲樹高，n 爲每個節點關鍵詞的個數；
-
儘可能少的磁盤 IO，加快了檢索速度；
-
可以支持範圍查找。
5. B+樹
B 樹和 B+樹有什麼不同呢？
第一，B 樹一個節點裏存的是數據，而 B+樹存儲的是索引（地址），所以 B 樹裏一個節點存不了很多個數據，但是 B+樹一個節點能存很多索引，B+樹葉子節點存所有的數據。
第二，B+樹的葉子節點是數據階段用了一個鏈表串聯起來，便於範圍查找。
Innodb 引擎和 Myisam 引擎的實現
Mysql 底層數據引擎以插件形式設計，最常見的是 Innodb 引擎和 Myisam 引擎，用戶可以根據個人需求選擇不同的引擎作爲 Mysql 數據表的底層引擎。我們剛分析了，B+樹作爲 Mysql 的索引的數據結構非常合適，但是數據和索引到底怎麼組織起來也是需要一番設計，設計理念的不同也導致了 Innodb 和 Myisam 的出現，各自呈現獨特的性能。
MyISAM 雖然數據查找性能極佳，但是不支持事務處理。Innodb 最大的特色就是支持了 ACID 兼容的事務功能，而且他支持行級鎖。Mysql 建立表的時候就可以指定引擎，比如下面的例子，就是分別指定了 Myisam 和 Innodb 作爲 user 表和 user2 表的數據引擎。
執行這兩個指令後，系統出現了以下的文件，說明這兩個引擎數據和索引的組織方式是不一樣的。
Innodb 創建表後生成的文件有：
-
frm:創建表的語句
-
idb:表裏面的數據+索引文件
Myisam 創建表後生成的文件有
-
frm:創建表的語句
-
MYD:表裏面的數據文件（myisam data）
-
MYI:表裏面的索引文件（myisam index）
從生成的文件看來，這兩個引擎底層數據和索引的組織方式並不一樣，MyISAM 引擎把數據和索引分開了，一人一個文件，這叫做非聚集索引方式；Innodb 引擎把數據和索引放在同一個文件裏了，這叫做聚集索引方式。下面將從底層實現角度分析這兩個引擎是怎麼依靠 B+樹這個數據結構來組織引擎實現的。
1. MyISAM 引擎的底層實現（非聚集索引方式）
MyISAM 用的是非聚集索引方式，即數據和索引落在不同的兩個文件上。MyISAM 在建表時以主鍵作爲 KEY 來建立主索引 B+樹，樹的葉子節點存的是對應數據的物理地址。我們拿到這個物理地址後，就可以到 MyISAM 數據文件中直接定位到具體的數據記錄了。
2. Innodb 引擎的底層實現（聚集索引方式）
InnoDB 是聚集索引方式，因此數據和索引都存儲在同一個文件裏。首先 InnoDB 會根據主鍵 ID 作爲 KEY 建立索引 B+樹，如左下圖所示，而 B+樹的葉子節點存儲的是主鍵 ID 對應的數據，比如在執行 select * from user_info where id=15 這個語句時，InnoDB 就會查詢這顆主鍵 ID 索引 B+樹，找到對應的 user_name='Bob'。
這是建表的時候 InnoDB 就會自動建立好主鍵 ID 索引樹，這也是爲什麼 Mysql 在建表時要求必須指定主鍵的原因。當我們爲表裏某個字段加索引時 InnoDB 會怎麼建立索引樹呢？比如我們要給 user_name 這個字段加索引，那麼 InnoDB 就會建立 user_name 索引 B+樹，節點裏存的是 user_name 這個 KEY，葉子節點存儲的數據的是主鍵 KEY。注意，葉子存儲的是主鍵 KEY！拿到主鍵 KEY 後，InnoDB 纔會去主鍵索引樹里根據剛在 user_name 索引樹找到的主鍵 KEY 查找到對應的數據。
問題來了，爲什麼 InnoDB 只在主鍵索引樹的葉子節點存儲了具體數據，但是其他索引樹卻不存具體數據呢，而要多此一舉先找到主鍵，再在主鍵索引樹找到對應的數據呢?
其實很簡單，因爲 InnoDB 需要節省存儲空間。一個表裏可能有很多個索引，InnoDB 都會給每個加了索引的字段生成索引樹，如果每個字段的索引樹都存儲了具體數據，那麼這個表的索引數據文件就變得非常巨大（數據極度冗餘了）。從節約磁盤空間的角度來說，真的沒有必要每個字段索引樹都存具體數據，通過這種看似“多此一舉”的步驟，在犧牲較少查詢的性能下節省了巨大的磁盤空間，這是非常有值得的。
在進行 InnoDB 和 MyISAM 特點對比時談到，MyISAM 查詢性能更好，從上面索引文件數據文件的設計來看也可以看出原因：MyISAM 直接找到物理地址後就可以直接定位到數據記錄，但是 InnoDB 查詢到葉子節點後，還需要再查詢一次主鍵索引樹，纔可以定位到具體數據。等於 MyISAM 一步就查到了數據，但是 InnoDB 要兩步，那當然 MyISAM 查詢性能更高。
本文首先探討了哪種數據結構更適合作爲 Mysql 底層索引的實現，然後再介紹了 Mysql 兩種經典數據引擎 MyISAM 和 InnoDB 的底層實現。最後再總結一下什麼時候需要給你的表裏的字段加索引吧：
-
較頻繁的作爲查詢條件的字段應該創建索引；
-
唯一性太差的字段不適合單獨創建索引，即使該字段頻繁作爲查詢條件；
-
更新非常頻繁的字段不適合創建索引。