共计 1268 个字符,预计需要花费 4 分钟才能阅读完成。
导读 | 什么是自适应哈希索引 (Adaptive Hash Index, AHI) 呢?原理又是怎样的呢?下面我们先从一个例子开始。 |
经常有朋友问,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 建了普通索引。假设表中有四条记录:
如上图,通过前序知识,容易知道 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 功能。
一个小知识点,希望对大家有帮助。
知其然,知其所以然。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)