MySQL中的哈希索引

mySQL中的哈希索引

在MySQL中，如果你使用的是Innodb存储引擎，那么经常会遇到B+树索引的概念，关于这个概念，之前的文章中我们讲过，除此之外，还有一种索引值得关注，那就是"哈希索引"。

先来介绍介绍关于哈希的一些知识，哈希是一种数据结构，最早是在数据结构这本书上看到的，也称之为散列表。具体是个啥意思呢，试想这样一种情况，假如我们要保存的数字有1,5,29，77,344,1908这6个数字，如果用一个数组来进行直接寻址，也就是直接查找数组的下标的方法来查询这几个关键字，那么我们的数组至少需要1908个元素，毫无疑问，这会造成空间浪费。哈希的引入，解决了这个问题，简单来理解，就是让这几个数字映射到一个小的集合里面，例如包含5个元素的集合，具体的映射方法就是对这些数字取余数，那么1将映射到1,5将映射到0,29将映射到4,77将映射到2,344将映射到4,1908将映射到3，那么我们就根据余数把这6个数字映射到了一个包含a[0]~a[4]的集合。这就是哈希最基本的原理，当然，映射的方法有很多，不一定是取余数。

这样做有一个比较直观的问题，就是有的数字映射到了集合中的同一个位置，把这种现象称之为哈希碰撞，解决这种碰撞最直接的办法就是使用链接法，就是映射到集合中同一位置的元素用链表进行链接，这样查询的时候，就可以直接去遍历这个链表进行查询了。

以上所述，是关于哈希的基本知识，想详细了解，还请关注数据结构之类的书籍。关于哈希索引，有些人说innodb支持哈希索引，还有人说innodb不支持哈希索引，那么结果到底是哪个呢？确切的说，对于Innodb的哈希索引，有以下特点：

1、Innodb的哈希索引不能由用户手动的创建。也就是常说的自适应哈希索引，站在这个角度来讲，确实不支持哈希索引。

2、Innodb会自动调优，如果判定自适应哈希索引能够提升效率，Innodb会自己建立相关的哈希索引，这个层面上讲，Innodb又支持哈希索引。

Innodb中哈希是怎样使用的呢？一般我们要查询一条记录，最最重要的就是定位到这条记录所在的数据页，还是用上面那几个数为例：1、5、29、77、344、1908，我们创建一个表，包含id和number两个字段，其中id字段为自增主键，number字段为一般的索引列，如果number的这几个数值都在不同的数据页上：

例如上面那样，这些数字都在不同的页号上，这些页号随机，互不相连，在这种情况下，我们频繁的对number进行查询，Innodb发现有很多类似：

select * from table where number=xxx的SQL，而这些SQL又不停的命中上面的几个数据页，如果我们用二级索引number列去查询，那么会造成innodb的"回表"操作（关于回表操作，之前索引那篇文章有讲过），这样比较麻烦。Innodb便会在自己的内存缓冲区（buffer_pool）里面开辟一片区域专门用来建立自适应的哈希索引，从而加速这个查询的速度。

从这个层面上来说，Innodb使用自适应哈希索引更像是对索引创建的一种索引，这种哈希索引为什么能加快查询速度？

这种哈希索引包含key-value值，它的key是我们查询的number的值，而value是这条记录所在的数据页的页面位置，这样通过number的值一次性就定位到了所在的数据页位置，避免了"回表"的这个过程，故而能加快查询的速度。

之所以称之为自适应哈希索引，就是因为我们不能认为的去干涉它，只能看着它"自生自灭",自己适应各种情况，对了，它的英文名字叫做"Adaptive Hash Index",简称AHI。

有优点也就有缺点，当然，缺点是和B+树索引对比而来的，Hash索引和B+ Tree索引的区别有：

1、哈希索引只能适用于等值查询，对于范围查询的场景，它无能为力，而B+ Tree索引可以轻松的处理；

2、有与哈希索引是K-V模式的，多个数据在存储关系上完全是无序的，所以哈希索引不能用于排序；

3、哈希索引不能支持多列联合索引的最左匹配规则，因为不同的值对应的hash结果不一样；

4、如果有大量的重复键值，这个时候，哈希索引高概率发生碰撞，这种情况下效率会很低；

目前的理解就这么多了，后续有新的内容会进行补充。