数据库索引为什么使用B+树而不是hashmap

最新推荐文章于 2024-01-14 15:30:46 发布
原创 最新推荐文章于 2024-01-14 15:30:46 发布 · 4.6k 阅读 · 8 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据库索引 #B+树 #hashmap

博客对比了hash表和B+树用于数据库索引的情况。指出hash表不能实现范围查找、不支持排序、难以支持部分索引查询，且数据量大时冲突概率高。而B+树非叶子节点只存索引，叶子节点存数据，更适合区间查询，通常用于数据库索引。

1、hash表只能匹配是否相等，不能实现范围查找

2、当需要按照索引进行order by时，hash值没办法支持排序

3、组合索引可以支持部分索引查询，如(a,b,c)的组合索引，查询中只用到了阿和b也可以查询的，如果使用hash表，组合索引会将几个字段合并hash，没办法支持部分索引
4、当数据量很大时，hash冲突的概率也会非常大
5、B+树作为索引时，非叶子节点只保存索引，叶子节点才会保存数据，这样方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。

面试官：MySQL索引为什么要用B+树实现？
小识的博客
08-27 1万+
原因如下 B+树能显著减少IO次数，提高效率 B+树的查询效率更加稳定，因为数据放在叶子节点 B+树能提高范围查询的效率，因为叶子节点指向下一个叶子节点 介绍 在从一堆数据中查找指定的数据时，我们常用的数据结构是哈希表和二叉查找树，表本质上就是一堆数据的集合，所以MySQL数据库用了哈希表和B+树来实现索引 B+树是通过二叉查找树，再由平衡二叉树，B树（又名B-树）演化而来的，B+树中的B不是代表二叉（binary），而是代表平衡（balance），因为B+树是从最早的平衡二叉树演化而来，但是B+树不.
【项目实战】MySQL 底层索引结构B+树变HashMap：性能与功能的博弈
奶爸的编程之路，也就一周冷个三天，欢迎关注我的微信公众号：本本本添哥
05-23 131
MySQL底层索引结构从B+树变为HashMap，将对业务系统产生显著影响。B+树适合范围查询和排序，数据持久化效率高，但内存占用较大；HashMap在等值查询上性能优越，插入删除操作简单，但不支持高效的范围查询和排序，且数据持久化难度增加。具体影响包括：查询性能上，HashMap在等值查询中表现更佳，而B+树在范围查询中更具优势；数据更新方面，HashMap操作简单，但哈希冲突可能影响性能；内存占用上，HashMap在负载因子合理时效率高，但冲突严重时内存占用增加；数据持久化上，B+树更适合磁盘存储。因此
为什么用 B+ 树做索引而不用哈希表做索引?
人总是要有梦想的QAQ的博客
03-27 1177
为什么用 B+ 树做索引而不用哈希表做索引? 1、哈希表是把索引字段映射成对应的哈希码然后再存放在对应的位置，这样的话，如果我们要进行模糊查找的话，显然哈希表这种结构是不支持的，只能遍历这个表。而B+树则可以通过最左前缀原则快速找到对应的数据。 2、如果我们要进行范围查找，例如查找ID为100 ~ 400的人，哈希表同样不支持，只能遍历全表。 3、索引字段通过哈希映射成哈希码，如果很多字段都刚好映...
为什么选择B+树作为数据库索引结构？
apu6370的博客
08-20 420
背景 首先，来谈谈B树。为什么要使用B树？我们需要明白以下两个事实： 【事实1】 不同容量的存储器，访问速度差异悬殊。以磁盘和内存为例，访问磁盘的时间大概是ms级的，访问内存的时间大概是ns级的。有个形象的比喻，若一次内存访问需要1秒，则一次外存访问需要1天。所以，现在的存储系统，都是分级组织的。最常用的数据尽可能放在更高层、更小的存储器中，只有在当前层找不到，才向更低层、更大的存储器中...
MySQL索引为什么使用B+树，而不用二叉树、红黑树、哈希表、B树？
折叠伞的博客
12-26 2503
索引是帮助MySQL高效获取数据的排好序的数据结构。 索引数据结构： 1.二叉树2.红黑树3.Hash表4.B-Tree。
MySQL数据库为什么大多使用B+树，而不是用Hash存储索引
一念永恒
12-20 5446
通常B+数据的查询时间为log(n),而利用Hash时间为o(1)，那为什么还要用B+树呢。 对于B+树，相比于Hash好处： 1.利用Hash需要把数据全部加载到内存中，如果数据量大，是一件很消耗内存的事，而采用B+树，是基于按照节点分段加载，由此减少内存消耗。 2.和业务场景有段，对于唯一查找（查找一个值），Hash确实更快，但数据库中经常查询多条数据，这时候由于B+数据的有序性，与叶子...
mysql b树子节点个数_Mysql 索引为什么要用B+数
weixin_39788382的博客
02-01 498
说点题外的：MySQL当中的 “My” 是什么意思？MySQL的发明者名叫 Michael “Monty” Widenius，MySQL是以他女儿的名字 “My” 来命名的。对这位发明者来说，MySQL数据库就仿佛是他可爱的女儿。她的二女儿叫什么呢？二女儿叫Maria，MariaDB名字的来源。正题：在从一堆数据中查找指定的数据时，我们常用的数据结构是哈希表和二叉查找树，表本质上就是一堆数据的集合...
为什么使用B+树而不是使用二叉树,红黑树,哈希表作为索引
weixin_47414034的博客
02-14 490
红黑树的树高还是太高了，比如当表里面有500w条记录 （也就是500w个索引），全部放到红黑树里面，树的高度会非常高，可能放完500w个索引，树的高度会达到20，所以可能要进行20次I/O操作，我们希望能够降低树的高度。显然，有了索引之后，只需要和磁盘做两次I/O即可，就可以找到key=89的结点，然后把这个结点的value值(磁盘中的文件地址)拿出来，去磁盘中的这个地址取出这行记录。只需要3次I/O即可。（3）B树没有冗余的重复的索引，B+树的非叶子节点和叶子节点有冗余的，重复的索引。
数据库索引——B+树索引（为什么使用B+树作为MySql的索引结构，用什么好处？）
your_棒棒糖的博客
05-12 1621
数据库索引——B+树索引 索引是一种数据结构，用于帮助我们在大量数据中快速定位到我们想要查找的数据。 索引最形象的比喻就是图书的目录了。注意这里的大量，数据量大了索引才显得有意义 索引在 MySQL 数据库中分三类： B+ 树索引 Hash 索引 全文索引 B+树索引 B+树进化具有的优点： 索引节点没有数据，比较小，能够完全加载到内存中 而且叶子节点之间都是链表的结构，所以B+Tree也是可以支持范围查询的，而B树每个节点key和data在一起，则无法区间查找 B+树中因为数据都在叶子节点，每次查询
mysql索引为什么要使用b+树 而不是Hash？
weixin_42612804的博客
02-11 563
MySQL 使用 B-Tree 而不是 Hash 索引是因为 B-Tree 有许多优点。 支持排序：B-Tree 索引可以支持排序，因此支持顺序查找。Hash 索引则不能支持排序，因此只支持随机查找。 支持范围查询：B-Tree 索引可以支持范围查询，因此支持区间查询，而 Hash 索引则不能。 支持分块查询：B-Tree 索引使用分块查询，因此可以支持大数据量的查询，而 Hash 索引则不...
数据库索引的原理，为什么要用 B+树，为什么不用二 叉树？
weixin_40725027的博客
05-08 1256
总体来说，我认为技术方案的选型，更多的要根据具体的业务场景来决定，并不一定是说B+树就是最好的选择，就像MongoDB里面采用B树结构，本质上来说，其实是关系型数据库和非关系型数据库的差异。
为什么要用B+树
qq_36042938的博客
01-14 1200
在节点分裂和合并时，IO操作少：B+树的叶子节点的大小是固定的，而且节点的大小一般都会设置为一页的大小，这就使得节点分裂和合并时，IO操作很少，只需读取和写入一页。支持范围查询：B+树在进行范围查询时，只需要从根节点一直遍历到叶子节点，因为数据都存储在叶子节点上，而且叶子节点之间有指针连接，可以很方便的进行范围查询。有利于缓存：B+树的非叶子结点只存储执行子节点的指针，二步存储数据，这样可以使得缓存能搞容纳更多的索引数据，从而提供缓存的命中率，加快查询速度。节点大小固定，可以存储更多的索引数据。
为什么Mysql用B+树做索引而不用B-树或红黑树或hash
weixin_36098377的博客
11-01 748
1、定义 索引是一种数据结果，帮助提高获取数据的速度 为了提高查找速度，有很多查询优化算法。但是每种查找算法都只能应用于特定数据结构之上。 索引就是数据库创建的满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据 2、索引数据结构 目前大部分数据库系统及文件系统都采用B Tree或其变种B+Tree作为索引结构 相关概念介绍 B-树（B树）：多路搜索树，每个结点存储M/2到M个关键字，非叶子结点存储指向关键字范围的子结点；所有关键字在整颗树中出现，且只出现一次，非叶子结点可以命中
为什么选择b＋树
qq_45453927的博客
06-10 318
b树中的每个结点存储了键值(key)以及非键值数据(data)，b＋树的非叶子结点只存储key，叶子结点存储key和data，当data数据量很大时，会导致b树的每个结点能够存储的key变少，因而树的高度增加，io次数增加，查询变慢。 此外，在涉及范围查询的时候，b＋树相较于b树而言，在叶子结点中间添加了双向指针，只需查询边界key,通过指针顺序(逆序)遍历叶子层即可，查询速度较快；而b树则需要进行树的遍历，相对耗时。 ...
为什么是B+树？
qq_40445523的博客
08-26 603
我们都知道在查询数据时为了避免全表扫描我们会加上索引，这样会极大的减少遍历次数，从而增加查询的效率。而索引本质是一种优化查询的数据结构。MySQL默认的索引数据结构为B+树。 有的张三可能就会问了，MySQL为什么要用B+树来作为默认的索引数据结构呢？为什么不能是hash，况且有那么多树结构，为什么偏偏选择B+树？ 这个疑问我当然也有，在查阅一番资料后，且听我一一道来。 一、hash结构 加速查询速度的数据结构通常见有两种： hash：hash是非常常见的数据类型，如hashMap就是通过对key做has
mysql为什么用B+树
兰陵笑笑生的博客
06-19 1501
为什么不用哈希(又名散列) 哈希表即散列表，原理就是用hash函数，将我们存的数据，以关键字的形式转换为hash值，然后根据hash值在内存中储存数据 无论读还是写，哈希都比树更快，那为什么索引结构要选用树型结构呢？因为对于分组、排序、比较，哈希型索引的时间复杂度会退化到O(n)，且实际应用中，数据量数百万级别后，时间比较长。 hash算法会存在hash冲突，尽管用了扰动函数，但数据量大了之后，还是会存在分布不均（扰动函数1，扰动函数2） 为什么不用二叉树 二叉树每个节点只分两个叉，每个节点只能存储一
数据库为什么用B+树
u012332679的博客
12-08 2562
作者：打码酱 链接：https://www.zhihu.com/question/62406977/answer/219108182 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 其实主要原因就是减少读写磁盘的次数。其它答主都已经回答了，我这里画蛇添足（把为什么三个字好好解释一番），较为详细的具体解释一下，不对的地方，还请海涵并敬请赐教。
为什么选择B+树，而不是B树，不是hash索引
Richard的博客
03-22 1068
为什么选择B+树，而不是B树，不是hash表数据库索引为什么使用B+树而不是hash索引为什么选择B树（B+树）不选择红黑树为什么是B+树不选择B树参考文章 数据库索引为什么使用B+树而不是hash索引 数据库索引为什么使用B+树而不是hash。 hash表只能匹配是否相等，不能实现范围查找，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索。 ...
为什么mysql索引用B+树而不用Hash表
JohnMin的博客
07-04 2469
由于Hash索引数据结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B+Tree 索引需要从根节点到枝节点，最后才能访问到叶子节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B+Tree 索引。虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端。...
mysql 索引为什么用 B+tree 而不用红黑树
最新发布
12-10
<think>我们讨论的是MySQL索引为何选择B+树而不是红黑树等结构。根据引用材料，主要原因包括磁盘IO效率、树的高度、节点存储方式等。以下将逐步分析： 1. **磁盘IO效率**： - B+树非叶子节点仅存储索引（键值）[^4]，不存储实际数据，因此每个节点能容纳更多键值。 - 红黑树每个节点存储一个键值+数据（或指针）[^2][^5]，导致节点体积大，树的高度更高。 - 公式推导：树高$h$与节点容量关系： - B+树：$h = \log_m N$（$m$为节点分叉数，$N$为数据总量） - 红黑树：$h = \log_2 N$ - **结论**：B+树高度远低于红黑树，减少磁盘IO次数（磁盘IO次数与树高正相关）[^1][^4]。 2. **范围查询性能**： - B+树叶节点形成双向链表[^3]，范围查询（如`WHERE id BETWEEN 10 AND 20`）只需一次遍历。 - 红黑树节点分散，范围查询需多次回溯遍历[^2]。 3. **节点利用率**： - B+树节点大小通常等于磁盘页大小（如16KB）[^3]，最大化单次IO数据加载量。 - 红黑树节点大小不固定，无法充分利用磁盘页空间[^5]。 4. **稳定性与维护成本**： - B+树分裂/合并操作更规则，仅影响相邻节点[^3]。 - 红黑树插入删除需频繁旋转和颜色调整，维护成本高。 ### 对比总结 | **特性** | **B+树** | **红黑树** | |----------------|-----------------------------------|--------------------------------| | **树高** | 低 ($\log_m N, m \gg 2$) | 高 ($\log_2 N$) | | **磁盘IO** | 少（节点利用率高） | 多（节点利用率低） | | **范围查询** | 高效（叶节点链表） | 低效（需遍历子树） | | **节点内容** | 非叶节点仅索引，叶节点存数据[^3] | 每个节点存键值+数据 | | **维护成本** | 分裂/合并规则化 | 旋转/变色频繁[^4] | > **核心结论**：B+树针对磁盘存储优化，减少IO次数；红黑树适合内存操作（如Java HashMap），但不适合磁盘数据库索引[^1][^3]。 §§相关问题§§ 1. B+树的具体分裂和合并过程是怎样的？ 2. MySQL中B+树的节点大小如何配置？ 3. 除了B+树和红黑树，还有哪些数据结构适合做数据库索引？ </think> MySQL 选择 B+树而非红黑树作为索引结构的核心原因在于**磁盘 I/O 效率**和**范围查询性能**的显著优势。以下是具体分析（关键结论参考引用[1][2][4][5]）： --- ### 一、核心原因：磁盘I/O效率优化 1. **更低的树高减少磁盘访问次数** - **红黑树**：平衡二叉树变体，树高为 $O(\log_2 N)$ - 百万数据需约 **20次磁盘I/O**（$2^{20} \approx 100万$） - **B+树**：多路平衡树，树高为 $O(\log_m N)$（$m$=节点分叉数） - 假设 $m=500$，百万数据仅需 **3次磁盘I/O**（$500^3 = 1.25亿$）[^1] - *原因*：B+树单节点可存储大量键值（如500个），红黑树单节点仅存1个键值 2. **节点设计适配磁盘特性** - B+树节点大小固定（通常=磁盘页大小，如16KB），单次I/O加载更多键值[^3] - 红黑树节点大小不固定，无法充分利用磁盘页空间[^4] --- ### 二、范围查询性能优势 | **操作** | **B+树** | **红黑树** | |------------------|------------------------------|--------------------------------| | 范围查询（如`id>100`） | 叶节点双向链表直接顺序扫描 | 需回溯遍历子树（时间复杂度高） | | 全表扫描 | 直接遍历叶节点链表 | 需中序遍历整棵树 | > **示例**：查询`WHERE id BETWEEN 1000 AND 2000` > - B+树：定位1000后沿链表扫描至2000（$O(1)$ 步长） > - 红黑树：对每个$id$执行独立查找（$O(\log_2 N)$ 每次） --- ### 三、存储效率对比 | **特性** | **B+树** | **红黑树** | |----------------|-------------------------------|--------------------------| | 非叶节点内容 | 仅存储键值（无数据） | 存储键值+数据指针 | | 叶节点内容 | 存储完整数据记录[^3] | 无特殊设计 | | 空间利用率 | 更高（非叶节点无冗余数据） | 较低 | > **公式推导**：假设树高$h$，单节点存储$m$个键值 > - B+树存储量：$S = m^h$ > - 红黑树存储量：$S = 2^h$ > 当$m \gg 2$时，B+树空间效率呈指数级优势[^1] --- ### 四、维护成本差异 - **B+树**：分裂/合并操作仅影响相邻节点，维护成本可控[^3] - **红黑树**：插入删除需频繁旋转和颜色调整（维护代价高） ```c // 红黑树插入后调整伪代码 while (父节点为红色) { if (叔节点为红色) 重新着色; else { 旋转操作（左旋/右旋）; 更新父节点颜色; } } ``` --- ### 五、为什么不用B树？ 虽然B树也是多叉树，但相比B+树仍有劣势： 1. **范围查询性能差**：B树非叶节点存储数据，无法形成高效链表扫描 2. **空间局部性差**：数据分散在各层节点，I/O效率低于B+树的连续叶节点[^5] --- ### 总结：B+树的不可替代性 | **需求** | **B+树支持** | **红黑树/B树缺陷** | |------------------|----------------------------|----------------------------| | 大规模数据 | ✅ 树高极低 | ❌ 树高过高导致I/O瓶颈 | | 范围查询 | ✅ 叶节点链表顺序访问 | ❌ 离散访问效率低 | | 磁盘页利用率 | ✅ 节点大小=磁盘页 | ❌ 无法充分利用页空间 | | 高并发写入 | ✅ 局部调整 | ❌ 红黑树全局调整代价高 | > **结论**：B+树通过**多叉结构降低树高**、**叶节点链表优化范围查询**、**分离索引与数据提升存储效率**，完美适配磁盘数据库场景[^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值