InnoDB到底支不支持哈希索引,为啥不同的人说的不一样?

继续回答水友提问(最近问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) ”哈希索引?

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

系统会不会判断失误,是不是一定能加速?

不是一定能加速,有时候会误判。

当业务场景为下面几种情况时:

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

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

  • 所有记录内存能放得下

AHI往往是有效的。


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

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

一个小知识点,希望解答了这位水友的疑问。

知其然,知其所以然。

欢迎大家扫码加入星球提问,有问必答。


画外音: 这里有网上可能没有的知识。

相关文章

数据库索引,到底是什么做的?

MyISAM与InnoDB的索引差异

作业:

在线看看,自己的业务有没有开启AHI?


画外音: 阅读原文,有惊喜。