经常有朋友问,MySQL的InnoDB到底支不支持哈希索引?
(1)InnoDB用户无法手动创建哈希索引,这一层上说,InnoDB确实不支持哈希索引;
(2)InnoDB会自调优
(self-tuning)
,如果判定建立自适应哈希索引
(Adaptive Hash Index, AHI)
,能够提升查询效率,InnoDB自己会建立相关哈希索引,这一层上说,InnoDB又是支持哈希索引的;
那什么是自适应哈希索引
(Adaptive Hash Index, AHI)
呢?原理又是怎样的呢?咱们先从一个例子开始。
t(id PK, name KEY, sex, flag)
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';
(2)再由主键,从聚集索引上二次遍历定位到记录(上图左边)。
不管聚集索引还是普通索引,记录定位的寻路路径
(Search Path)
都很长。
在MySQL运行的过程中,如果InnoDB发现,有很多SQL存在这类很长的寻路,并且有很多SQL会命中相同的页面
(page)
,InnoDB会在自己的内存缓冲区
(Buffer)
里,开辟一块区域,建立自适应哈希所有AHI,以加速查询。
从这个层面上来说,InnoDB的自使用哈希索引,更像“
索引的索引
”,毕竟其目的是为了加速索引寻路。
为啥叫“自适应
(adaptive)
”哈希索引?
系统自己判断“应该可以加速查询”而建立的,不需要用户手动建立,故称“自适应”。
(1)很多单行记录查询(例如passport,用户中心等业务);
(2)索引范围查询(此时AHI可以快速定位首行记录);
(3)所有记录内存能放得下;
当业务有大量like或者join,AHI的维护反而可能成为负担,降低系统效率,此时可以手动关闭AHI功能。
一个小知识点,希望对大家有帮助。
知其然,知其所以然。
架构师之路
架构师之路,坚持撰写接地气的架构文章
636篇原创内容
Official Account
《》