哈希索引

只有Memory引擎支持哈希索引(不讨论NDB集群支持唯一哈希索引的情况)

哈希索引基于哈希表实现,只有精确匹配索引所有列的查询才有效。

存储引擎会根据所有的索引计算出一个哈希码

哈希索引将所有的哈希码存储在索引中,同时在哈希表中保存指向每个数据行额指针。

因为索引只是只需要存储对应的哈希值,所以索引的结构十分紧凑,使得哈希表查询非常快。

哈希表有一下限制:

哈希索引只包含哈希值和行指针,而不存储字段值,所以不能使用索引中值来避免行读取

哈希索引不是按照索引顺序存储的,因此也无法用于排序

哈希索引不支持部分索引匹配,因为哈希索引是根据全部索引列计算的哈希码

哈希索引只支持等值比较查询,=、in、<=>,不支持范围查询例如where a>100

访问哈希索引非常快,除非是哈希冲突,当出现哈希冲突时,存储引擎必须遍历链表中所有的行指针,逐行比较,直到找到符合条件的行

验证“哈希索引基于哈希表实现,只有精确匹配索引所有列的查询才有效”

举例:

CREATE TABLE `white_user` (

`id` bigint(20) NOT NULL AUTO_INCREMENT,

`teacherEmail` varchar(30) DEFAULT NULL,

`whiteFlag` int(1) DEFAULT ‘0‘,

`creationTime` datetime DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `PK_INDEX` (`teacherEmail`,`whiteFlag`) USING HASH

) ENGINE=MEMORY AUTO_INCREMENT=64 DEFAULT CHARSET=utf8;

针对以下四种情况:只有前两种可以使用到hash索引

第一种:EXPLAIN select id,t.teacherEmail from white_user t where whiteflag=1 and teacheremail=‘testdemo2‘;

第二种:EXPLAIN select id,t.teacherEmail from white_user t where teacheremail=‘testdemo2‘ and whiteflag=1 ;

第三种:EXPLAIN select id,t.teacherEmail from white_user t where teacheremail=‘testdemo2‘;

第四种:EXPLAIN select id,t.teacherEmail from white_user t where whiteflag=1 ;

Innodb引擎对哈希索引的使用

Innodb引擎有一个特殊的功能叫做“自适应哈希索引”,当Innodb注意到某些索引值被使用的非常频繁时,它会在内存中给予b-tree索引之上再创建一个哈希索引,这样就让b-tree索引页具有哈希索引的一些优点,比如快速哈希查找,这种完全自动的、内部的行文。

Innodb引擎可以模拟哈希索引,在表上创建一个伪哈希索引,也可以享受哈希索引 带来的便利,例如可以存储很小的索引就可以为超长的字段创建索引。

建议使用CRC32哈希函数,不建议使用SHA1和MD5哈希函数,因为后两个函数得出的哈希码非常长,会浪费大量空间,做比较时也慢。但是SHA1和MD5哈希函数进行的是强加密函数,设计目标是最大限度的消除冲突。

如果表非常大的话,CRC32哈希函数会出现大量哈希冲突,可以考虑自己实现一个64位的哈希函数。

举例:

CREATE TABLE `white_user` (

`id` bigint(20) NOT NULL AUTO_INCREMENT,

`teacherEmail` varchar(30) DEFAULT NULL,

`whiteFlag` int(1) DEFAULT ‘0‘,

`hashCode` varchar(255) DEFAULT NULL,

`creationTime` datetime DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `PK_INDEX` (`teacherEmail`,`whiteFlag`) USING BTREE),

KEY `PK_HASHCODE` (`hashcode`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=64 DEFAULT CHARSET=utf8;

新增数据时,hashcode字段中应该存储CRC32(teacheremail)获得的哈希码

执行下面条件时,可以使用到

EXPLAIN select id,t.teacherEmail from white_user t where hashcode=CRC32(‘testdemo2‘) AND whiteflag=1 and teacheremail=‘testdemo2‘;

这样就可以利用哈希索引加快查询速度,同时对超大字段尽心索引。

原文地址:https://www.cnblogs.com/use-D/p/9557547.html

时间: 2024-10-29 15:58:24

哈希索引的相关文章

MySQL中自适应哈希索引

自适应哈希索引采用之前讨论的哈希表的方式实现,不同的是,这仅是数据库自身创建并使用的,DBA本身并不能对其进行干预.自适应哈希索引近哈希函数映射到一个哈希表中,因此对于字典类型的查找非常快速,如SELECT * FROM TABLE WHERE index_col='xxx'但是对于范围查找就无能为力.通过SHOW ENGINE INNODB STATUS 可以看到当前自适应哈希索引的使用情况 ------------------------------------- INSERT BUFFER

SQL Server2014 哈希索引原理

SQL Server2014 哈希索引原理 翻译自:http://www.sqlservercentral.com/blogs/sql-and-sql-only/2015/09/08/hekaton-part-6-hash-indexes-intro/ 跟哈希 join,哈希 聚合的原理一样,了解哈希索引的原理也会同时明白哈希 join和哈希 聚合的原理 SQL Server 2014推出的的新索引类型叫做 hash index.介绍hash index之前一定要介绍哈希函数这样会让大家更明白哈

自适应哈希索引

InnoDB存储引擎会监控对表上索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引,所以称之为自适应(adaptive)的.自适应哈希索引通过缓冲池的B+树构造而来,因此建立的速度很快.而且不需要将整个表都建哈希索引,InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引. 根据InnoDB的官方文档显示,启用自适应哈希索引后,读取和写入速度可以提高2倍:对于辅助索引的连接操作,性能可以提高5倍.在我看来,自适应哈希索引是非常好的优化模式,其设计思想是数据库自优化

MySql 自适应哈希索引

一.介绍 哈希(hash)是一种非常快的查找方法,一般情况下查找的时间复杂度为O(1).常用于连接(join)操作,如SQL Server和Oracle中的哈希连 接(hash join).但是SQL Server和Oracle等常见的数据库并不支持哈希索引(hash index).MySQL的Heap存储引擎默认的索引类型为哈希, 而InnoDB存储引擎提出了另一种实现方法,自适应哈希索引(adaptive hash index). InnoDB存储引擎会监控对表上索引的查找,如果观察到建立哈

MySQL B+树索引和哈希索引的区别

导读 在MySQL里常用的索引数据结构有B+树索引和哈希索引两种,我们来看下这两种索引数据结构的区别及其不同的应用建议. 二者区别 备注:先说下,在MySQL文档里,实际上是把B+树索引写成了BTREE,例如像下面这样的写法: CREATE TABLE t(aid int unsigned not null auto_increment,userid int unsigned not null default 0,username varchar(20) not null default ‘’,

B+树索引和哈希索引的区别[转]

导读 在MySQL里常用的索引数据结构有B+树索引和哈希索引两种,我们来看下这两种索引数据结构的区别及其不同的应用建议. 二者区别 备注:先说下,在MySQL文档里,实际上是把B+树索引写成了BTREE,例如像下面这样的写法: CREATE TABLE t(aid int unsigned not null auto_increment,userid int unsigned not null default 0,username varchar(20) not null default ‘’,

MySQL B+树索引和哈希索引的区别(转 JD二面)

导读 在MySQL里常用的索引数据结构有B+树索引和哈希索引两种,我们来看下这两种索引数据结构的区别及其不同的应用建议. 二者区别 备注:先说下,在MySQL文档里,实际上是把B+树索引写成了BTREE,例如像下面这样的写法: CREATE TABLE t(aid int unsigned not null auto_increment,userid int unsigned not null default 0,username varchar(20) not null default '',

MySQL中的自适应哈希索引

众所周知,InnoDB使用的索引结构是B+树,但其实它还支持另一种索引:自适应哈希索引. 哈希表是数组+链表的形式.通过哈希函数计算每个节点数据中键所对应的哈希桶位置,如果出现哈希冲突,就使用拉链法来解决.更多内容可以参考 百度百科-哈希表 从以上可以知道,哈希表查找最优情况下是查找一次.而InnoDB使用的是B+树,最优情况下的查找次数根据层数决定.因此为了提高查询效率,InnoDB便允许使用自适应哈希来提高性能. 可以通过参数 innodb_adaptive_hash_index 来决定是否

mysql在B-Tree上创建伪哈希索引

构建哈希的过程 select过程 长字符串下,构建索引可通过自定义哈希作为索引,本人通过实验,在3百多个数据记录的下,性能效果很明显,完全不是一个等级.以下为索引前后几种情况对比 无索引的url:直接通过无索引url 通过构建url的哈希索引:用bigint类型存储索引字段crc_url 在哈希索引下,几乎都是0秒完成. 当然,如果直接使用url作为索引,即用B-Tree存储url存储的内容会很大. 题外话: 在where字句中,优化器会根据查询条件是否存在索引,优先进行索引查询. 如下为例子: