Mysql索引之聚合式索引之InnoDB之B+Tree

Mysql索引之聚合式索引之InnoDB之B+Tree

在开始分享B+Tree数据结构时我们先来了解一下与索引相关的数据结构都用哪些?
  • 二叉树
  • 红黑树
  • hash表
  • B-Tree
  • B+Tree

首先来了解一下二叉树的数据结构的特性:
   二叉树是把数据分成左右两个分支,在左分支上是存储的比父节点小的数据,而在右侧分支存贮着比父节点大的数据,当我们查找数据的时候,根据要查找的数据,去判断是大于父节点还是小于父节点,小于父节点则去左侧查找,反之则查询右边。但是如果父节点的数据是最小值,且后面插入的数据是一次递增的话,就会形成单边增长的单边树,此时不仅树的深度会变得无限大,而且查询时树有多深就要多少次IO,非常消耗时间,在这种情况下,我们肯定不会考虑使用二叉树这种数据结构来作为我们的索引方案。如下图所示:
第二是红黑树的数据结构的特性
  红黑树也叫平衡树,它更相当于是二叉树的一个升级版,弥补了二叉树单边存储的不足,在新增数据时,他的父级节点是会实时变化的,每个父级节点下有最多两个叶子节点,左边叶子节点存储了比父级小的数据,右边存储比它大的数据,且每个父级节点最多只能拥有两个叶子节点,正是他的这一特性,让他未能变成索引方案中最优的解决方案。因为他虽然解决了单边存储的问题,但并未解决二叉树的存储深度问题,在数据量大的时候,还是要通过N次IO才能去找到我们最后想要的数据,显然这是不符合我们程序员天下武功,唯快不破的崇高理念的。pass!!!
第三就是hash表:
  hash表的数据结构存储是把我们索引上的数据转换成acsii码然后和我们的索引上的数据指向的内存地址做一个映射关系。
  当使用哈希表进行查询的时候,就是再次使用哈希函数将key转换为对应的数组下标,并定位到该空间获取value,如此一来,就可以充分利用到数组的定位性能进行数据定位。在Mysql索引方案选择中,我们可以选择使用hash来作为索引方案,但是,对于我们实际使用场景中来说,hash表在使用范围查找sql时,由于Hash操作并不能保证顺序性,所以值相近的两个数据,Hash值相差很远,被分到不同的桶中。同时,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询,哈希索引也不支持多列联合索引的最左匹配规则。总之就日常开发而言,弊大于利。
第四个是B-Tree:
  B-Tree的最大特点是可以横向扩展多个节点,每个节点下的节点数量相同,每个节点下都存放了数据,这样既解决了二叉树的不平衡问题,也解决了红黑树的深度问题,是个比较好的方案,但对于范围查找来说,这种数据结构是远远不满足我们的日常需求的。于是B+Tree便成为索引的最佳解决方案。

在这里插入图片描述
以下便是万众期待的B+Tree的数据结构特性分享:
在这里插入图片描述
  B+Tree从名字上看,它和B-Tree是有紧密联系的数据结构,它是在B-Tree的基础上,对BTree做了一个提升,B+Tree的所有非叶子节点是不存储任何数据的,存储的只有索引对应的key,在末端的叶子节点上存储了一份完整的数据信息,且前个叶子节点通过指针,指向下一个叶子节点,这样就保证了我们无论是精确查询,还是范围查询都能快速的将我们想要的数据查询出来,Innodb也正是利用B+Tree的这一特性来完成我们数据库的索引查询。
  当然,有B+Tree也分为聚合索引和辅助索引(secondary index)。上面的B+Tree示例图在数据库中的实现即为聚集索引,聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据。辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据,而是存储相应行数据的聚集索引键,即主键。当通过辅助索引来查询数据时,InnoDB存储引擎会遍历辅助索引找到主键,然后再通过主键在聚集索引中找到完整的行记录数据。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值