MySQL到底支不支持哈希索引？

经常有朋友问，MySQL的InnoDB到底支不支持哈希索引？

创新互联服务项目包括吴桥网站建设、吴桥网站制作、吴桥网页制作以及吴桥网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，吴桥网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到吴桥省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

对于InnoDB的哈希索引，确切的应该这么说：

(1)InnoDB用户无法手动创建哈希索引，这一层上说，InnoDB确实不支持哈希索引；

(2)InnoDB会自调优(self-tuning)，如果判定建立自适应哈希索引(Adaptive Hash Index, AHI)，能够提升查询效率，InnoDB自己会建立相关哈希索引，这一层上说，InnoDB又是支持哈希索引的；

那什么是自适应哈希索引(Adaptive Hash Index, AHI)呢？原理又是怎样的呢？咱们先从一个例子开始。

不妨设有InnoDB数据表：

t(id PK, name KEY, sex, flag)

画外音：id是主键，name建了普通索引。 假设表中有四条记录：

• 1, shenjian, m, A
• 3, zhangsan, m, A
• 5, lisi, m, A
• 9, wangwu, f, B

如上图，通过前序知识，容易知道InnoDB在主键id上会建立聚集索引(Clustered Index)，叶子存储记录本身，在name上会建立普通索引(Secondary Index)，叶子存储主键值。

发起主键id查询时，能够通过聚集索引，直接定位到行记录。

select * from t where name='ls';

发起普通索引查询时：

(1)会先从普通索引查询出主键(上图右边)；

(2)再由主键，从聚集索引上二次遍历定位到记录(上图左边)。

不管聚集索引还是普通索引，记录定位的寻路路径(Search Path)都很长。

在MySQL运行的过程中，如果InnoDB发现，有很多SQL存在这类很长的寻路，并且有很多SQL会命中相同的页面(page)，InnoDB会在自己的内存缓冲区(Buffer)里，开辟一块区域，建立自适应哈希所有AHI，以加速查询。

从这个层面上来说，InnoDB的自使用哈希索引，更像“索引的索引”，毕竟其目的是为了加速索引寻路。

既然是哈希，key是什么，value是什么？

key是索引键值(或者键值前缀)。

value是索引记录页面位置。

为啥叫“自适应(adaptive)”哈希索引？

系统自己判断“应该可以加速查询”而建立的，不需要用户手动建立，故称“自适应”。

系统会不会判断失误，是不是一定能加速？

不是一定能加速，有时候会误判。 当业务场景为下面几种情况时：

(1)很多单行记录查询(例如passport，用户中心等业务);

(2)索引范围查询(此时AHI可以快速定位首行记录);

(3)所有记录内存能放得下;

AHI往往是有效的。

画外音：任何脱离业务的技术方案，都是耍流氓。

当业务有大量like或者join，AHI的维护反而可能成为负担，降低系统效率，此时可以手动关闭AHI功能。

一个小知识点，希望对大家有帮助。

知其然，知其所以然。

当前文章：MySQL到底支不支持哈希索引？
转载注明：http://www.shufengxianlan.com/qtweb/news17/67267.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联