当前位置: 首页 > 编程笔记 >

MySQL btree索引与hash索引区别

红经亘
2023-03-14
本文向大家介绍MySQL btree索引与hash索引区别,包括了MySQL btree索引与hash索引区别的使用技巧和注意事项,需要的朋友参考一下

在MySQL中,大多数索引(如 PRIMARY KEY,UNIQUE,INDEX和FULLTEXT)都是在BTREE中存储,但使用memory引擎可以选择BTREE索引或者HASH索引,两种不同类型的索引各自有其不同的使用范围。

  • B树索引具有范围查找和前缀查找的能力,对于有N节点的B树,检索一条记录的复杂度为O(LogN)。相当于二分查找。
  • 哈希索引只能做等于查找,但是无论多大的Hash表,查找复杂度都是O(1)。

显然,如果值的差异性大,并且以等值查找(=、 <、>、in)为主,Hash索引是更高效的选择,它有O(1)的查找复杂度。
如果值的差异性相对较差,并且以范围查找为主,B树是更好的选择,它支持范围查找。

一、HASH索引

利用哈希函数,计算存储地址,检索时不需要像Btree那样,从根节点开始遍历,逐级查找。

Hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引。

可能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?任何事物都是有两面性的,Hash 索引也一样,虽然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端,主要有以下这些。

(1)Hash 索引仅仅能满足”=”,”IN”和”<=>”查询,不能使用范围查询(查询范围时 慢)。

由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值,所以它只能用于等值的过滤,不能用于基于范围的过滤,因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系,并不能保证和Hash运算前完全一样。

(2)Hash 索引无法被用来避免数据的排序操作。

由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值,而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样,所以数据库无法利用索引的数据来避免任何排序运算;

(3)Hash 索引不能利用部分索引键查询。

对于组合索引,Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值,而不是单独计算 Hash 值,所以通过组合索引的前面一个或几个索引键进行查询的时候,Hash 索引也无法被利用。

(4)Hash 索引在任何时候都不能避免表扫描。

前面已经知道,Hash 索引是将索引键通过 Hash 运算之后,将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中,由于不同索引键存在相同 Hash 值,所以即使取满足某个 Hash 键值的数据的记录条数,也无法从 Hash 索引中直接完成查询,还是要通过访问表中的实际数据进行相应的比较,并得到相应的结果。

(5)Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。

对于选择性比较低的索引键,如果创建 Hash 索引,那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦,会浪费多次表数据的访问,而造成整体性能低下。

二、B+树

如图所示,如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次IO,在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,内存时间因为非常短(相比磁盘的IO)可以忽略不计,通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO,29在26和30之间,锁定磁盘块3的P2指针,通过指针加载磁盘块8到内存,发生第三次IO,同时内存中做二分查找找到29,结束查询,总计三次IO。真实的情况是,3层的b+树可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高。

  • b+树性质

1.索引字段要尽量的小:

通过上面的分析,我们知道IO次数取决于b+数的高度h,假设当前数据表的数据为N,每个磁盘块的数据项的数量是m,则有h=㏒(m+1)N,当数据量N一定的情况下,m越大,h越小;而m = 磁盘块的大小 / 数据项的大小,磁盘块的大小也就是一个数据页的大小,是固定的,如果数据项占的空间越小,数据项的数量越多,树的高度越低。这就是为什么每个数据项,即索引字段要尽量的小,比如int占4字节,要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点,一旦放到内层节点,磁盘块的数据项会大幅度下降,导致树增高。当数据项等于1时将会退化成线性表

2.索引的最左匹配特性(即从左往右匹配):

当b+树的数据项是复合的数据结构,比如(name,age,sex)的时候,b+数是按照从左到右的顺序来建立搜索树的,比如当(张三,20,F)这样的数据来检索的时候,b+树会优先比较name来确定下一步的所搜方向,如果name相同再依次比较age和sex,最后得到检索的数据;但当(20,F)这样的没有name的数据来的时候,b+树就不知道下一步该查哪个节点,因为建立搜索树的时候name就是第一个比较因子,必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时,b+树可以用name来指定搜索方向,但下一个字段age的缺失,所以只能把名字等于张三的数据都找到,然后再匹配性别是F的数据了, 这个是非常重要的性质,即索引的最左匹配特性。

以上就是MySQL btree索引与hash索引区别的详细内容,更多关于MySQL btree索引与hash索引的资料请关注小牛知识库其它相关文章!

 类似资料:
  • 问题内容: 我在MySQL数据库中有下表: SQL将如下所示: 如您所见,我同时创建了primaryId和和imgDate索引键。我的想法是,该WHERE子句使用primaryId,而ORDER子句使用来查询结果imgDate。 我的问题是,现在使用多索引会更好吗?还是我应该使用多列索引(目前我不太了解)? 这是我从EXPLAIN得到的: 注意:这不是使用多列索引,这是使用上表说明的结果。 问题答

  • 我有大量相同类型的实体,每个实体都有大量属性,并且我只有以下两种选择来存储它们: 将每个项存储在索引中并执行多索引搜索 将所有enties存储在单个索引中,并且只搜索1个索引。 一般而言,我想要一个时间复杂度之间的比较搜索“N”实体与“M”特征在上述每一种情况!

  • 问题内容: 缓存解决方案和索引解决方案之间的真正区别是什么?在我看来,索引解决方案实际上是具有运行搜索查询功能(例如:Elastic Search)的缓存。是否有任何真正的理由在同一项目中同时使用缓存解决方案和索引解决方案,或者索引解决方案基本上会使其他任何缓存变得多余? 示例:假设我对ElasticSearch使用NEST,它将存储并返回POCO;如果我随后查询ElasticSearch并已将P

  • 我最近开始在nutch上工作,我试图理解它是如何工作的。据我所知,Nutch基本上是用来抓取web的,Solr/Lucene是用来索引和搜索的。但是当我阅读nutch的文档时,它说nutch也做倒排索引。它是否在内部使用Lucene来进行索引,或者它是否有其他一些用于索引的库?如果它使用solr/Lucene进行索引,那么为什么有必要像nutch教程所说的那样用nutch配置solr呢? 是默认情

  • 主要内容:索引,下载索引,构件搜索我们知道,Maven 中央仓库为用户提供了多达数十万构件,而 Nexus 可以代理所有的远程仓库(包括 Maven 中央仓库),可见 Nexus 仓库中构件的数量相当庞大。用户想要在这么多构件中,快速的查找自己所需的构件,一个最直接有效的方式就是:搜索。 Nexus 作为一款成熟的仓库管理工具,它通过维护仓库的索引提供了构件搜索功能,以便帮助用户方便快速地找到所需构件。 本节我们将详细为您介绍 N

  • 本文向大家介绍postgresql 索引之 hash的使用详解,包括了postgresql 索引之 hash的使用详解的使用技巧和注意事项,需要的朋友参考一下 os: ubuntu 16.04 postgresql: 9.6.8 ip 规划 192.168.56.102 node2 postgresql help create index [ USING method ] method 要使用的索