一、索引類型

1.B+樹

為什么是B+樹而不是B樹？

首先看看B樹和B+樹在結構上的區(qū)別

B樹結構：

B+樹：

可以看到：

• B樹在每個節(jié)點上都有衛(wèi)星數(shù)據(數(shù)據表中的一行數(shù)據)，而B+樹只在葉子節(jié)點上有衛(wèi)星數(shù)據。這意味著相同大小的磁盤扇區(qū)，B+樹可以存儲的葉子節(jié)點更多，磁盤IO次數(shù)更少；同樣也意味著B+樹的查找效率更穩(wěn)定，而B樹數(shù)據查詢的最快時間復雜度是O(1)。
• B樹的每個節(jié)點只出現(xiàn)一次，B+樹的所有節(jié)點都會出現(xiàn)在葉子節(jié)點中。B+樹的所有葉子節(jié)點形成一個升序鏈表，適合區(qū)間范圍查找，而B樹則不適合。
  

2.MyISAM和InnoDB的B+樹索引實現(xiàn)方式的區(qū)別(聚簇索引和非聚簇索引)？

首先需要了解聚簇索引和非聚簇索引。

聚簇索引：

在聚簇索引中，葉子頁包含了行的全部數(shù)據，節(jié)點頁值包含索引列。InnoDB通過主鍵聚集數(shù)據，如果沒有定義主鍵則選擇一個唯一的非空索引列代替；如果沒有這樣的索引，InnoDB會隱式定義一個主鍵來作為聚簇索引。

聚簇索引的數(shù)據分布：

?在聚簇索引中，除了主鍵索引，還有二級索引。二級索引中的葉子節(jié)點存儲的不是“行指針”，而是主鍵值，并以此作為指向行的“指針”。這意味著通過二級索引查找行，存儲引擎需要找到二級索引的葉子節(jié)點獲得對應的主鍵值，然后根據這個值去聚簇索引中查找對應的行，也稱為“回表”。當然，可以通過覆蓋索引避免回表或者InnoDB的自適應索引能夠減少這樣的重復工作。

注意：聚簇索引中每一個葉子節(jié)點不止包含完整的數(shù)據行，還包括事務ID、用于事務和MVCC的回滾指針。

3.非聚簇索引

非聚簇索引的主鍵索引和二級索引在結構上沒有什么不同，都在葉子節(jié)點上存儲指向數(shù)據的物理地址的“行指針”。

聚簇索引的主鍵索引和二級索引：

非聚簇索引的主鍵索引和二級索引：

4.聚簇索引的優(yōu)缺點

優(yōu)點：

把相關數(shù)據保存在一起（比如用用戶ID把用戶的全部郵件聚集在一起），否則每次數(shù)據讀取就可能導致一次磁盤IO
數(shù)據訪問更快，把索引和數(shù)據保存在同一個B+樹中，通常在聚簇索引中獲取數(shù)據比在非聚簇索引中查找更快
使用覆蓋查詢可以直接利用頁節(jié)點中的主鍵值

缺點：

如果所有數(shù)據都可以放在內存中，順序訪問不再那么必要，聚簇索引沒有優(yōu)勢
插入速度依賴于插入順序，隨機插入會導致頁分裂，造成空洞，使用OPTIMIZE TABLE重建表
每次插入、更新、刪除都需要維護索引的變化，代價很高
二級索引可能比想象中大，因為在節(jié)點中包含了引用行的主鍵列

5.哈希索引

哈希索引基于哈希表實現(xiàn)，只有精確匹配索引所有列的查詢才有效，這意味著，哈希索引適用于等值查詢。

具體實現(xiàn)：對于每一行數(shù)據，存儲引擎都會對所有的索引列計算一個哈希碼，哈希索引將所有的哈希碼存儲在索引中，同時在哈希表中保存指向每個數(shù)據行的指針。

在MySQL中，只有Memory引擎顯式支持哈希索引，當然Memory引擎也支持B樹索引。

注意:Memory引擎支持非唯一哈希索引，解決沖突的方式是以鏈表的形式存放多個哈希值相同的記錄指針。

6.自適應哈希索引

InnoDB注意到某些索引值被使用得非常頻繁時，會在內存中基于B+樹索引之上再創(chuàng)建一個哈希索引，這樣就讓B+樹索引也具有哈希索引的一些優(yōu)點，比如快速的哈希查找。

到此這篇關于MySQL索引底層數(shù)據結構詳情的文章就介紹到這了,更多相關MySQL索引底層數(shù)據結構內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論