索引的底層原理
MySQL支持兩種索引，一種是B-樹（B樹）索引，一種是哈希表索引，這兩種索引的查詢效率較高。
MYSQL中InnoDB存儲引擎是（基於B-樹 ，實際MYSQL採用的是B+樹) 的索引結構。
B-樹的特點：
B-樹是一種 m 階平衡樹，葉子節點都在同一層，由於每一個節點存儲的數據量比較大，索引在整個B-樹的層數是比較低的，基本上不超過三層。
爲什麼將B-樹的節點大小一般設置爲和磁盤塊大小一致 ？
索引是以文件的形式存儲在磁盤上，磁盤每次往內存加載數據是有基本單位的，磁盤的讀取是按block塊操作的（內存是按page頁面操作的），因此B-樹的節點大小一般設置爲和磁盤塊大小一致，從磁盤加載一個節點到內存裏面，加載一個B-樹節點，就相當於加載一個block塊，這樣就可以通過一次磁盤I/O把一個磁盤塊的數據全部存儲下來，有多少節點，則僅需要加載多少次。
目的：在進行節點讀取或者存儲的過程，保證磁盤I/O的操作次數是最少的。
（MySQL的讀寫效率，主要集中在磁盤I/O上）。
MySQL爲什麼要採用 B+ 樹存儲索引結構呢而不是 B- 樹？
- B-樹的每一個節點，存儲的是 關鍵字和對應的數據地址，而B+樹的非葉子節點只存關鍵字，不存數據地址。因此B+樹的每一個非葉子節點存儲的關鍵字是遠遠多於B-樹的，B+樹的葉子節點存放關鍵字和數據，從樹的高度上來說，B+樹的高度要小於B-樹，使用的磁盤I/O次數少，因此查詢會更快一些。（相同數量的節點數，B+樹存放的數據多，相同數量的數據，B+樹節點數就少 -> 樹的高度可能就小 -> 查詢的效率就會高）
- B-樹由於每個節點都存儲關鍵字和數據，因此離根節點近的數據，查詢的就快，離根節點遠的數據，查詢的就慢，耗時不均勻；B+樹所有的數據都存在葉子節點上，因此在B+樹上搜索關鍵字，找到對應數據的時間是比較平均的，沒有快慢之分。
- 在B-樹上如果做區間查找，遍歷的節點是非常多的，B+樹是能夠很好滿足的；
B+樹所有葉子節點被連接成了有序鏈表結構，因此做整表遍歷和區間查找是非常容易的。
哈希索引：
是由哈希表實現的，哈希表對數據無法做到排序，因此不適合做區間查找，效率非常低，需要搜索整個哈希表結構。