HASH索引，AVL树，B树，B+树的区别？

程序猿ZhangSir

已于 2024-03-28 19:04:24 修改

阅读量686

点赞数

分类专栏： # MySQL 数据库文章标签：哈希算法 b树算法

于 2023-08-16 10:00:00 首次发布

本文链接：https://blog.csdn.net/m0_70325779/article/details/132210278

版权

数据库同时被 2 个专栏收录

32 篇文章 0 订阅

订阅专栏

MySQL

26 篇文章 2 订阅

订阅专栏

提前声明，本篇文章是我对我之前B+树那篇文章的追加部分和补充的知识点，建议各位在看本篇文章的时候时已经了解了数据库索引B+树的基本原理，否则有些地方可能理解起来会多一些难度哦！

深入理解索引B+树的基本原理_程序猿ZhangSir的博客-CSDN博客https://blog.csdn.net/m0_70325779/article/details/132182698?spm=1001.2014.3001.5501

5. 为什么数据库不采用哈希表存储数据呢？

6. 为什么数据库不采取B树的结构存储数据呢？

7. 为什么数据库不采用AVL树存储数据呢？

8. 自适应 Hash 索引

1. 什么是 Hash

1.1 Hash 函数

Hash 本身其实是一个函数，又被称为散列函数，它可以大幅提高我们对数据的检索效率。因为它是散列的，所以在存储数据的时候，它也是无序的。

Hash 算法是通过某种确定性的算法(例如MD5，SHA1，SHA2，SHA3)将输入转变成输出，相同的输入结果永远会得到相同的输出。

1.2 Hash 碰撞

熟悉Java中 HashMap 的同学应该知道，我们在往 Map 集合中存放元素的时候，它会先对要往集合中存放的元素的 key 值做一个哈希运算，从而确定它要存入的位置。理论上每一个对象都会存放在不同的地方，但当存放的对象越来越多时，有可能后来添加的元素的 key 值计算得出的结果与之前已经存入的元素的 key 的哈希值相等，这种现象就被称为哈希碰撞。当产生哈希碰撞的时候，我们会将后添加的元素与之前就已经存在的元素形成一个链表，当再次发生哈希碰撞时，就继续在链表尾部添加即可。

如下图所示，我们也可以采取这种方式将数据库中的数据以哈希的方式存储到哈希表中，可以看到h(k2)与h(k5) 就产生了哈希碰撞，如果我们两个数据都想要存储，就可以让 h(k5) 追加在 h(k2) 的后面形成链表，当我们想要获取 h(k5) 元素的时候，遍历链表即可。

1.3 HashMap 的时间复杂度

HashMap 是一个数组，它是有下标的，我们在 查询/删除/修改 元素的时候，都可以直接通过哈希函数计算出来的哈希值精确到某个元素的位置，这里不考虑哈希碰撞形成的链表，因此 HashMap 的查询/删除/修改元素的时间复杂度都是O(1)，也就是常量级别的，可以说是非常非常快。

2. AVL树

2.1 简单了解AVL树

AVL树，其实也叫平衡二叉树，或叫平衡二叉搜索树，它通常满足一个特点，左子节点的值都比父节点小，右子节点的值都比父节点大，如下图所示

在这种情况下，我们去寻找数据91

（1）先查找根节点34，比91小，所以91在34的右半部分；

（2）查询到89，还比91小，所以91在89的右半部分；

（3）继续向下查找，就找到了元素91，只需要查找三次即可得出结果；

（4）如果查到最后没有找到，说明想要查找的元素在AVL树中不存在；

2.2 AVL树的时间复杂度

从上面举得例子不难看出，在AVL树中查找数据时，每查找一次，砍掉一半的数据，再查找一次，再砍掉一半的数据，所以不难看出，AVL树的时间复杂度是 O(log2n)。

2.3 AVL树的缺点

AVL树时间复杂度虽然低，但也存在一些缺点。因为AVL树要保持高度的平衡，所以需要经常性旋转，而旋转是非常耗费时间和性能的。并且，随着数据越来越多，AVL树的深度也会越来越大，如下图所示，当数据达到31个的时候，AVL树的高度已经有5层了。要知道，每多一层，与磁盘就要多进行一次IO操作，磁盘交互的速度是比较慢的，非常耗费时间，所以我们就在想，能不能把树的高度降低一些，但同时又能存足量的元素呢？这就有了下面要说M叉树，也可以理解为B树。

3. B 树

经过了刚才对AVL树的分析，我们也知道了，当树的枝杈越多时，存储的数据也越多，与磁盘交互的次数也越少，我们把上方的二叉树转换成三叉树，当然也可以转换成四叉树，五叉树都是可以的，这里我就以三叉树为例。

这个时候，我们还是能存储31个元素，并且树的高度由原来的5层降低到了4层，提高了我们数据的查找效率，这就是我们数据库索引的雏形，我们就可以将数据库中的数据存储在树中，得到如下简易模型

上图中就是索引最开始形成的B树结构图，左上角也有标注，这个时候我们可以看到，在原始B树中，磁盘块1，2，3，4这几个非根节点中还存放着数据呢。

根节点磁盘块P1的地址值指向磁盘块2，并且里面记录的主键值都是小于26的；

根节点磁盘块P2是地址值指向磁盘块3，里面记录的数据主键值都是在26与35之间的；

根节点磁盘块P3是地址值指向磁盘块4，里面记录的数据主键值都是大于35的；

根节点磁盘块的 26和35则是两条完整的数据，假若我们要查询的就是26或35，就会直接返回数据，不需要再往下面继续查找；

下方的磁盘块 2，3，4 中都是同理，依次往下类推。

这种数据的存储方式和查找方式性能已经非常优秀了，但是还有一个缺点，我们将原来的2叉树转变成M多叉树，目的就是为了存储更多的数据，但大家看，在磁盘块 2，3，4 中，P1，P2，P3都是指针，不会占用多少空间，但8和12的data存储的是真实的数据(一个指针可能只占用四个或八个字节，但一条真实的数据可能占用上百字节)，会占用更多的磁盘空间，而且这个时候还有分成了三段，如果分的段更多，也会存储更多的数据，这就会导致我们无法存储更多的指针数据，违背了我们的初衷。于是，我们就可以对这个 B 树做进一步的升级(当然也不只是因为这一个原因，后面我们还会说到，这里先说这一点)，演化成了我们现在的 B+ 树结构。

4. B+ 树

如上图所示，就是从B树演化形成的 B+ 树，在 B+ 书中，我们舍弃了B书中非叶子节点也存储真实数据做法，将所有的真实数据全部存放在叶子节点中，这样我们的目录页就可以存放更多的指针数据。并在每一页都会添加一个数组，数组中记录着该页中的所有元素并按照从小到大的顺序排列。

例如上图，顶层目录页33记录了数据（1，30），（320，33），意思就是有主键值在[1，320）之间的数据相关信息存储在页30中，主键值大于320之后的数据相关信息存储在页33中，可以根据对应的地址值去对应的页中查找数据；

中间目录页30中存储着（1，10），（5，28），（12，9），（209，20）。数据存储方式与顶层目录页一样；当我们想要查找（100，9，x）这条数据时，先在顶层目录页做判断，判断相关信息应该存储在页30当中，然后在中间页30中继续查找（100，9，x）的相关信息，经过判断发现该数据存放在页9中，根据对应的地址值找到页9，然后在页9中就可以获取到数据（100，9，x）了，不管查询哪条数据，都是这样的一个过程，查询速度非常稳定，并且中间目录页不存储真实数据只存储地址值，可以存储更多的叶子节点页数据。

5. 为什么数据库不采用哈希表存储数据呢？

这其实是一个面试题，刚才我们也分析过了，哈希表的时间复杂度为O(1)，常量级别，是最快的，那么数据库存储数据时为什么不采用哈希表的形式存储呢？原因有以下几点：

（1）范围查找显得无力

如果我们采用哈希表的结构存储，你会发现，它只能满足我们对精准值得查找，当我们在数据库中加入了BETWEEN...AND...或IN这些范围查找关键字的时候，哈希表就没有优势了，而且哈希表还是乱序的，这就导致我们在进行范围查找时，时间复杂度为会从O(1)退化成O(n)，而我们的树形结构时间复杂度稳定在O(log2n)，这个时候我们就会发现，哈希表就没有优势了；

（2）排序浪费时间

因为哈希表是乱序存储，当我们需要进行ORDER BY 的时候，每次ORDER BY底层都要排一次序，而我们的树形结构在存储是就是有序的，不管什么时候取数据都省去了排序的时间。我们存储；

（3）不太支持联合索引

B+树中是支持联合索引的，并会对联合主键依次进行排序，如果我们使用哈希表存储数据，当我们将字段C1与字段C2联合作为主键时，哈希存储就会把C1和C2作为一个整体计算哈希值，不会单个做哈希值计算。这样就乱套了，因为两个不一样的字段加在一起哈希值是可能相同的，会产生哈希碰撞，查询时可能会查询出错误的数据，无法满足我们的查询要求；

（4）索引列重复时效率低

计算哈希值就是为了避免哈希碰撞，如果一些字段肯定会出现碰撞，例如性别，年龄这些字段，那么哈希碰撞的概率就会非常大，它会遍历哈希碰撞产生的链表上的每一个元素，依次作比较，非常耗时，所以哈希索引通常不会用在容易出现重复的字段上；