为什么MySQL索引选择B+树而不使用B树?

为什么mysql索引选择B+树而不使用B树?


1. 关于mysql查询效率:

在这里插入图片描述


2. 关于分块读取:

在这里插入图片描述


3. 关于数据格式存储:

在这里插入图片描述


4. 关于合适的数据结构:哈希表,树

哈希表:

在这里插入图片描述
分析:

    1. 哈希表是散列表,存储在其中的数据是无序的, 所以当进行范围查询的时候,需要挨个便利,效率较低;
    1. 存储过程中会出现哈希碰撞,哈希冲突,必须要设计应能优良的哈希算法;
    1. 存储的过程中,可能会造成存储空间的浪费;
    1. mysql的 memory 存储引擎是 哈希索引;mysql的 innodb 中有一个特性叫做 自适应hash;

在这里插入图片描述

数据结构在线动态展示:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

如:一个二叉树:单个节点只存储一条数据,单个节点至多有两个子节点。
在这里插入图片描述
随着数据量的增加,树的层数自然也要增加,而树的层数的增加会导致io次数的增加(每层一次io),为了存储更多的数据而不增加io次数,引入了多叉树,即B树

B树

如下:我们选择了一个度为4(每个节点至多存储3条数据)的B树,同样的数据量的存储,我们的树的层数由原本的4层,变成了2层,减少了io查询次数。
在这里插入图片描述
那么,随之而来的又有一个问题,三层的b树能存储多少条数据呐?

B树的存储结构:每个节点可存储多条数据,且存储了对应的键值,指针和数据。

在这里插入图片描述
分析:
innodb默认页的大小是16k,每个树的节点除了存储数据之外,还包含键值指针,我们假设理想模式下,一个数据是1k,那么第一层最多最多存储16条数据;第二层,就是第一层的16个指针对应第二层的16个节点,我们也假设每个节点最多存储16条,那么第二层至多存储数据也就是16 * 16条;第三层,就是第二层的16 * 16个指针,我们也假设每个节点最多存储16条,那么第三层至多存储就是16 * 16 * 16条数据,综上,三层B树最多能存储的数据就是 16 + 16 * 16 + 16 * 16 * 16 = 4368,而实际上一定是小于这个数的,所以三层的B树至多也就存储4000多条数据

4000条数据显然不满足我们平时数据库的存储使用,那么怎么才能存储更多的数据呐?B树继续加层数?多一层就多一次io,代价比较高,不适合;那么,还有另外一种方案,就是每个节点存储尽可能多的数据,因此引入了B+树

B+树

如下:度为4(每个节点至多存储3条数据)的B+树,同样数据量的存储
在这里插入图片描述
B+树的存储结构:上层节点只存储指针和键值,最底层叶子节点存储键值和数据,并且叶子节点之间是链式环结构。与B树相比,上层节点可以存储更多的数据,且叶子节点的范围查询或分页查询效率更高。

在这里插入图片描述
那么,三层的B+树能存储多少条数据呐?

分析:

指针和键值的大小肯定远小于数据的大小,假设指针+键值占用10Byte,innodb默认页的大小是16k,那么第一层磁盘块能存储的指针+键值就是16 * 1024 / 10 = 1600(约等于),假设第一层1600个 指针 指向第二层1600个子节点,第二层的每个子节点一样至多存储指针+键值16 * 1024 / 10 = 1600(约等于),那么第二层总共存储的指针+键值总数就是 1600 * 1600,第三层假设只存储数据,每条数据1k,每个节点至多可以存储16条数据,第二层的1600 * 1600个指针对应第三层的1600 * 1600个子节点,那合起来就是 1600 * 1600 * 16 = 4096 0000条数据;

不同的数据类型,肯定会影响存储的数据量,一般结论是:

3层B+树大概可以存:
主键为bigint:约2000w
主键为int:约4000w

因此,与B树相比,B+树显然可以存储更多的数据量


5. 问题总结:

    1. 一般innodb索引层数有几层?
      解析:
      一般情况下,3-4层,因为3-4层的B+树足以支撑千万级别的数据存储;
    1. 索引列的键(key)值怎么选?
      解析:
      innodb非叶子节点的存储是 指针+键值,指针一般变化不大,所以索引列要尽可能选择占用空间小的字段,因为占用越小,单个节点能存储的 指针+键值 自然就更多,存储的数据自然就更多。
    1. 创建表的时候,主键是否需要自增?
      解析:
      需要,因为如果不自增,会带来索引维护成本的提高,造成叶分裂,而自增只需要在后面有序排列,因此,在满足业务场景的前提下,能自增尽量设置成自增;
    1. 一张表可以有多少个索引?
      解析:
      理论上来说没有索引个数的限制,但并不是索引越多越好。
    1. 一个索引对应一棵树还是多个索引对应多棵树?
      解析:
      一个索引一棵树
    1. 索引的叶子节点要存放数据,当多个索引存在的时候,数据放几份?
      解析:
      一份
    1. 如果数据存储一份,其他索引的叶子节点存储什么数据?
      解析:
      官方文档写的是 primary key,翻译过来的话是 主键,但是回答 聚簇索引的列值 更为准确;
      因为,在innodb的存储引擎中,mysql在数据插入的时候,必须要选择某一个索引列绑定在一起,如果有主键,选择主键,如果没有主键,就会选择唯一键,如果没有唯一键,那么mysql会自动生成一个6字节的rowId来进行存储。

聚簇索引:跟数据绑定存储的称之为聚簇索引;
非聚簇索引:没有跟数据绑定存储的称之为非聚簇索引;
如:
一个表中有 id,name, age, gender, address等字段,其中id为主键,name为普通索引;
那么,id就是聚簇索引,name就是非聚簇索引。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: MySQL 使用 B-Tree 而不是 Hash 索引是因为 B-Tree 有许多优点。 1. 支持排序:B-Tree 索引可以支持排序,因此支持顺序查找。Hash 索引则不能支持排序,因此只支持随机查找。 2. 支持范围查询:B-Tree 索引可以支持范围查询,因此支持区间查询,而 Hash 索引则不能。 3. 支持分块查询:B-Tree 索引使用分块查询,因此可以支持大数据量的查询,而 Hash 索引则不能。 4. 支持磁盘存储:B-Tree 索引可以使用磁盘存储,因此占用内存较少,而 Hash 索引则需要使用内存,因此内存占用较多。 因此,B-Tree 索引比 Hash 索引更适合用于大数据量的数据库系统,特别是在排序和范围查询等方面。 ### 回答2: MySQL使用B-tree而不是Hash索引是为了更好地支持范围查询和排序操作。Hash索引是基于哈希算法的索引,它将索引值直接映射到哈希表中的位置,可以实现非常快速的查找操作。但是,它并不适合处理范围查询和排序操作。 首先,Hash索引是无序的,无法支持范围查询。范围查询需要按一定的顺序访问索引中的数据,而Hash索引无法提供这样的顺序。 其次,Hash索引在处理排序操作时效率较低。排序操作需要根据索引中的数据值进行排序,但是Hash索引中的数据值是无序的,因此需要额外的操作来实现排序。 而B-tree索引是一种平衡的树状数据结构,可以支持按范围查询和排序操作。B-tree索引索引值按顺序组织在树中的节点中,可以在树的节点之间进行高效的跳跃和遍历,从而实现快速的范围查询和排序操作。 此外,B-tree索引适用于磁盘存储,而不仅仅是内存存储。数据库中的数据通常存储在磁盘上,而不是全部加载到内存中。B-tree索引的结构特性能够适应磁盘存储的特点,减少磁盘IO次数,提高索引的检索效率。 综上所述,为了更好地支持范围查询和排序操作,并适应磁盘存储的特点,MySQL选择使用B-tree而不是Hash索引。 ### 回答3: MySQL索引使用B树而不是哈希的主要原因有三个。 首先,B树适合磁盘存储,而哈希适合内存存储。在磁盘上,数据是分块存储的,每个块可以容纳多个数据。B树的结构能够更有效地利用磁盘上的块,减少磁盘I/O次数,提高数据的读取效率。而哈希则不适合磁盘存储,因为哈希表需要一次完成整个表的读取,对于大型数据量的表来说,哈希表会导致大量的磁盘I/O,性能较差。 其次,B树适合范围查询,而哈希不适合。在MySQL中,经常需要使用范围查询,如大于、小于、区间等。B树的有序特性使得范围查询非常高效,只需要遍历指定范围的节点即可。而哈希表的数据分布是随机的,无法提供有序性,无法高效地支持范围查询。 最后,B树支持数据的顺序访问,而哈希不支持。B树的左子树保存的是小于父节点的数据,右子树保存的是大于父节点的数据,这种有序性使得B树能够很好地支持数据的顺序访问。而哈希表的数据分布是随机的,无法提供有序性,不能有效地支持数据的顺序访问。 综上所述,由于MySQL索引需要适应磁盘存储、范围查询和数据的顺序访问,B树是一种更适合的数据结构,而哈希表在这些方面表现较差,因此MySQL索引选择使用B树而不是哈希。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值