前言
一、索引類型
B+樹
為什么是B+樹而不是B樹？
首先看看B樹和B+樹在結構上的區(qū)別
可以看到：
B樹在每個節(jié)點上都有衛(wèi)星數(shù)據(jù)(數(shù)據(jù)表中的一行數(shù)據(jù))，而B+樹只在葉子節(jié)點上有衛(wèi)星數(shù)據(jù)。這意味著相同大小的磁盤扇區(qū)，B+樹可以存儲的葉子節(jié)點更多，磁盤IO次數(shù)更少；同樣也意味著B+樹的查找效率更穩(wěn)定，而B樹數(shù)據(jù)查詢的最快時間復雜度是O(1)。
B樹的每個節(jié)點只出現(xiàn)一次，B+樹的所有節(jié)點都會出現(xiàn)在葉子節(jié)點中。B+樹的所有葉子節(jié)點形成一個升序鏈表，適合區(qū)間范圍查找，而B樹則不適合。
MyISAM和InnoDB的B+樹索引實現(xiàn)方式的區(qū)別(聚簇索引和非聚簇索引)？
首先需要了解聚簇索引和非聚簇索引。
聚簇索引
在聚簇索引中，葉子頁包含了行的全部數(shù)據(jù)，節(jié)點頁值包含索引列。InnoDB通過主鍵聚集數(shù)據(jù)，如果沒有定義主鍵則選擇一個唯一的非空索引列代替；如果沒有這樣的索引，InnoDB會隱式定義一個主鍵來作為聚簇索引。
在聚簇索引中，除了主鍵索引，還有二級索引。二級索引中的葉子節(jié)點存儲的不是“行指針”，而是主鍵值，并以此作為指向行的“指針”。這意味著通過二級索引查找行，存儲引擎需要找到二級索引的葉子節(jié)點獲得對應的主鍵值，然后根據(jù)這個值去聚簇索引中查找對應的行，也稱為“回表”。當然，可以通過覆蓋索引避免回表或者InnoDB的自適應索引能夠減少這樣的重復工作。
PS：聚簇索引中每一個葉子節(jié)點不止包含完整的數(shù)據(jù)行，還包括事務ID、用于事務和MVCC的回滾指針。
非聚簇索引
非聚簇索引的主鍵索引和二級索引在結構上沒有什么不同，都在葉子節(jié)點上存儲指向數(shù)據(jù)的物理地址的“行指針”。
聚簇索引的優(yōu)缺點
優(yōu)點
把相關數(shù)據(jù)保存在一起（比如用用戶ID把用戶的全部郵件聚集在一起），否則每次數(shù)據(jù)讀取就可能導致一次磁盤IO
數(shù)據(jù)訪問更快，把索引和數(shù)據(jù)保存在同一個B+樹中，通常在聚簇索引中獲取數(shù)據(jù)比在非聚簇索引中查找更快
使用覆蓋查詢可以直接利用頁節(jié)點中的主鍵值
缺點
如果所有數(shù)據(jù)都可以放在內(nèi)存中，順序訪問不再那么必要，聚簇索引沒有優(yōu)勢
插入速度依賴于插入順序，隨機插入會導致頁分裂，造成空洞，使用OPTIMIZE TABLE重建表
每次插入、更新、刪除都需要維護索引的變化，代價很高
二級索引可能比想象中大，因為在節(jié)點中包含了引用行的主鍵列
哈希索引
哈希索引基于哈希表實現(xiàn)，只有精確匹配索引所有列的查詢才有效，這意味著，哈希索引適用于等值查詢。
具體實現(xiàn)：對于每一行數(shù)據(jù)，存儲引擎都會對所有的索引列計算一個哈希碼，哈希索引將所有的哈希碼存儲在索引中，同時在哈希表中保存指向每個數(shù)據(jù)行的指針。
在MySQL中，只有Memory引擎顯式支持哈希索引，當然Memory引擎也支持B樹索引。
PS:Memory引擎支持非唯一哈希索引，解決沖突的方式是以鏈表的形式存放多個哈希值相同的記錄指針。
自適應哈希索引
InnoDB注意到某些索引值被使用得非常頻繁時，會在內(nèi)存中基于B+樹索引之上再創(chuàng)建一個哈希索引，這樣就讓B+樹索引也具有哈希索引的一些優(yōu)點，比如快速的哈希查找
