带有哈希索引的 MySQL InnoDB 表答案

【问题标题】：MySQL InnoDB table with a Hash Index带有哈希索引的 MySQL InnoDB 表
【发布时间】：2017-12-03 09:23:42
【问题描述】：

我有一张这样的桌子。

ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

后来我创建了一个这样的 HASH 索引。

CREATE INDEX index ON table (column) USING HASH;

后来我尝试了一些解释查询。

喜欢

explain Select * from table where column=132;

我看到引擎正在使用 possible_keys 上的索引，并且在关键内容中显示了索引的名称！！

但是在文档中说 InnoDB 现在不允许散列索引我想知道为什么我的 innoDB 据说允许散列索引？

【问题讨论】：

【解决方案1】：

InnoDB 默默地将“HASH”更改为“BTree”。 BTree 索引的功能与 HASH 的功能相同，此外还有更多功能。或者你认为有什么好的理由需要 Hash？

“很好的理由”——MySQL 是多年前创建的。它的设计初衷是“精益求精”。许多特性被归结为“一刀切”：用于索引的 BTree； JOINing 等的嵌套循环连接

同时，为了将来的扩展和伪兼容性，包括了一些常见的语法变体——HASH 用于索引，DESC 用于索引排序等。即使那些“撒谎”会发生什么，数据库引擎仍然给你“正确”的答案。

随着时间的推移，最明显的捷径已经得到修复。

请注意列表是如何从“必须拥有”到“很高兴拥有”的顺序排列的。未来可能包括

与此同时，有些东西正在消失（或已经消失——在 MariaDB 或 MySQL 中）

【讨论】：

好吧，哈希是关于没有任何排序的特定键，因此插入不会强制系统重新排序 btree。如果我总是知道自己想要什么，并且我的主要操作是“给出 id xyz 的东西”，那么哈希索引应该具有 O(1) 与 O(log n)。哈希索引不是为范围操作而构建的，所以缺点仍然存在，有很多充分的理由希望在 btree 上进行哈希，否则。
@shadowdroid - BTrees 有时需要处理块；哈希有时需要建立一个“链”。对于十亿行，O(log n) 约为 5。
感谢您指出这一点。它不会改变有时哈希索引是一个完全有效的选择的事实。尤其是如果我没有范围，例如，如果我将加密数据存储为某些链接的密钥，那么一次性链接 BTREE 有点没用。仍然在大多数情况下，在 SQL 中，我们希望选择范围，因此对我来说 BTREE 是大多数应用程序的更好选择。我去是为了“好理由”。可能有充分的理由，这就是我想说的。
@shadowdroid - 我在答案中添加了详细说明“充分理由”。

【解决方案2】：

InnoDB中的特性叫做自适应哈希索引，

是否使用哈希索引取决于表的规模和查询频率，完全是内部策略，通常不配置。

【讨论】：