文章目录

  • 一、 B+Tree(B-Tree变种)
  • 二、B-tree 和B+tree 对比：
  • 三、二叉树和B+Tree对比
  • 四、Red/Black Tree 和B+Tree对比
  • 五、总结：

问题：为什么索引要使用B+TREE?

一、 B+Tree(B-Tree变种)

  1. 数据结构
    非叶子节点不存储data，只存储索引(冗余)，可以放更多的索引
    叶子节点包含所有索引字段
    叶子节点用指针连接，提高区间访问的性能
    (注：B+Tree本身没有双向链表结构，MySQL将其用作索引结构时加上了双向链表)

    整个叶子节点包含了整张表的索引
    所有节点都是有序的，不管是节点内还是节点之间，数据都是排好序的

查询流程：比如查30
MySQL会先将根节点都load到RAM（内存）中，通过折半查找得出30在15和56之间，然后将15和56之间的叶子节点load到RAM中通过折半查找得出30在20和49之间，然后再load20和49之间的叶子节点，再通过折半查找对比，找到30，在内存中查找不耗费性能，磁盘I/O才耗费性能

2.那为什么用B+Tree结构用做索引的数据结构呢？
这是B+Tree的结构所决定的。

3.举个例子：
MySQL一个节点的大小是16KB
比如用bigInt 做主键 ， 1bigInt = 8byte 。
下一个节点的磁盘文件地址 大概 6byte

mysql有索引为什么不走 mysql索引为啥用b+树_mysql有索引为什么不走


16kb/(8+6b) =1170

用B+Tree存储索引，一个节点最少可以放1170个元素

当B+ tree都被放满的时候，可放元素： 1170* 1170*16 = 21902400
及仅3层就可以放两千多万的数据。

所以两千多万条数据，利用索引，扫描3次就可以找到，如果用普通的表要扫描成千上万次。

这就是为什么不加索引的查询用几十秒，而加了索引只需要几十或几百毫秒。

二、B-tree 和B+tree 对比：

mysql有索引为什么不走 mysql索引为啥用b+树_子节点_02

一颗B- tree ， 一个索引元素最大1kb ，那一个节点只能放16个元素 ，如果要放满两千万的话：
16的n次方 = 两千万 ，树的高度：n远远大于3

三、二叉树和B+Tree对比

索引也是存在磁盘上的，用二叉树也是会和磁盘做很多次交互的。
对于单边增长的数据，二叉树和普通表没有区别。


mysql有索引为什么不走 mysql索引为啥用b+树_子节点_03

四、Red/Black Tree 和B+Tree对比

红黑树加入了反转、平衡，但是如果500万条记录，树的高度会很高，如果要查找的元素锁在的叶子节点，查询的高度不可控，对MySQL查找帮助并不大。


mysql有索引为什么不走 mysql索引为啥用b+树_mysql_04

五、总结：

B+Tree能战胜其他数据结构成为索引的数据结构，是因为
a.树的高度可控
b.数据都是顺序存储
c.改造之后，叶子节点间存在双向链表，找到一个节点便可按顺序继续查询，不许要再返回根节点重新查找