MYSQL索引为什么要用B树?

本文介绍了磁盘预读原理和局部性原理,阐述了为何磁盘I/O次数是评价索引性能的关键因素。B-Tree和B+Tree作为索引结构,B+Tree由于其特殊结构,能有效减少磁盘I/O次数,尤其适合外存索引。在实际应用中,B+Tree的出度更高,性能更优。总结了B+Tree作为数据库索引的原因在于其高效的I/O性能和对磁盘预读的优化。
摘要由CSDN通过智能技术生成

转自https://blog.csdn.net/u013967628/article/details/84305511
貌似也不是原作者

局部性原理与磁盘预读

由于存储介质的特性,磁盘本身存取就比主存慢很多,再加上机械运动耗费,磁盘的存取速度往往是主存的几百分分之一,因此为了提高效率,要尽量减少磁盘I/O。为了达到这个目的,磁盘往往不是严格按需读取,而是每次都会预读,即使只需要一个字节,磁盘也会从这个位置开始,顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理:

  • 当一个数据被用到时,其附近的数据也通常会马上被使用。
  • 程序运行期间所需要的数据通常比较集中。

由于磁盘顺序读取的效率很高(不需要寻道时间,只需很少的旋转时间),因此对于具有局部性的程序来说,预读可以提高I/O效率。

预读的长度一般为页(page)的整倍数。页是计算机管理存储器的逻辑块,硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块,每个存储块称为一页(在许多操作系统中,页得大小通常为4k),主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时,会触发一个缺页异常,此时系统会向磁盘发出读盘信号,磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中,然后异常返回,程序继续运行。

B-/+Tree索引的性能分析

到这里终于可以分析B-/+Tree索引的性能了。

上文说过一般使用磁盘I/O次数评价索引结构的优劣。先从B-Tree分析,根据B-Tree的定义,可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理,将一个节点的大小设为等于一个页,这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的,在实际实现B-Tree还需要使用如下技巧:

每次新建节点时,直接申请一个页的空间,这样就保证一个节点物理上也存储在一个页里,加之计算机存储分配都是按页对齐的,就实现了一个node只需一次I/O。

B-Tree中一次检索最多需要h-1次I/O(根节点常驻内存),渐进复杂度为O(h)=O(logdN)O(h)=O(logdN)。一般实际应用中,出度d是非常大的数字,通常超过100,因此h非常小(通常不超过3)。注:为什么h能做到这么小?因为每一层有100个指针的话,h为三层,那总数据量就可以达到100^3即100万级别。

综上所述,用B-Tree作为索引结构效率是非常高的。

而红黑树这种结构,h明显要深的多。由于逻辑上很近的节点(父子)物理上可能很远,无法利用局部性,所以红黑树的I/O渐进复杂度也为O(h),效率明显比B-Tree差很多。

上文还说过,B+Tree更适合外存索引,原因和内节点出度d有关。从上面分析可以看到,d越大索引的性能越好,而出度的上限取决于节点内key和data的大小:

dmax=floor(pagesize/(keysize+datasize+pointsize))

floor表示向下取整。由于B+Tree内节点去掉了data域,因此可以拥有更大的出度,拥有更好的性能。

图1: B+树的结构以及与磁盘存储的关系(可能有误)
在这里插入图片描述

总结

非常感谢原文作者,这篇文章加了一点我自己的理解,可能有些出入(我自己面试用没问题)。

现在回到最初的问题:为什么MySql用B+树做索引?

  • 磁盘I/O耗时难以容忍,这是诱因
  • B+树查询只需要h-1次磁盘I/O
    如果面试官又问,为什么只需要h-1次磁盘I/O?
  • B+树的性质决定每次查询最多需要查询h个节点
  • 每个B+树节点被存储在一个磁盘页中
  • 一次磁盘页读取对应一次I/O操作
### 回答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、付费专栏及课程。

余额充值