具有哈希索引的MySQL InnoDB表

Question

我有这样的桌子。

ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

稍后，我创建了像这样的散列索引。

CREATE INDEX index ON table (column) USING HASH;

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

喜欢

explain Select * from table where column=132;

我看到引擎正在possible_keys上使用索引，在关键内容中写着索引的名称！！

但是在文档中说InnoDB现在不允许哈希索引，我想知道为什么我的innoDB应该允许哈希索引？

Answer 1

InnoDB悄悄地将“散列”更改为"BTree“。BTree索引可以像散列那样执行，还有更多。或者你觉得有什么好的理由想要哈什？

“很好的理由”-- MySQL是许多年前创建的。它被设计成“瘦削和刻薄”。许多特性归结为“一刀切”：用于索引的BTree；用于JOINing的嵌套循环连接等等。

同时，为了将来的扩展和伪兼容性，还包括了一些常见的语法变体--用于索引的HASH、用于索引排序的DESC等等。尽管这些“谎言”将发生什么，但数据库引擎仍然给出了‘正确’的答案。

随着时间的推移，最显眼的捷径已经得到了补救。

• 复制(3.xx?)
• 事务(在4.0中添加InnoDB ) (MyISAM有LOCK TABLES，但这并不足够)。
• information_schema (4.1?)(相对于各种SHOW命令)注意: 8.0用“数据字典”对其进行了大修)
• 字符集和排序规则(4.1) (vs "latin_swedish_ci"，对实现者来说足够好)。
• 存储例程(vs客户端代码) (5.0)
• 子查询(TEMPORARY TABLEs不够)
• 各种JOIN优化(5.6、5、7、8.0)
• only_full_group_by (MariaDB 10.1，5.7)
• ALTER并不总是复制表(大部分是5.7)
• “生成”列(5.7)
• “表空间”(5.7)
• JSON数据类型和函数
• FULLTEXT和SPATIAL索引在InnoDB中(5.7，8.0) (因此MyISAM可以被废弃)
• DESC in INDEXes (8.0) (很少有用例真正需要这个)
• “窗口”函数(MariaDB 10.2，然后是MySQL 8.0)
• CTE (MariaDB 10.2，然后MySQL 8.0)
• 安全性:更好的密码处理(4.1、5.6、8.0)
• HA (高可用性) (MariaDB与Galera；8.0与InnoDB集群)
• 静止加密(8.0?)

注意列表是如何从“必须有”到“好有”排序的。但未来可能包括

• 多线程执行(如果你是I/O绑定的话也没用)
• HASH索引(和其他类型)
• 全球UNIQUE和FOREIGN KEY为PARTITIONing。(这并不是分区非常有用。)
• 与标准和其他供应商更好的语法兼容性(MariaDB已经在这方面做得更好了)

与此同时，有些事情正在消失(或者已经消失了--无论是在MariaDB还是MySQL)。

• 为多种计算机(如Atari )进行编译
• Query -方便于基准测试，但在生产环境中并不真正有用。以及在任何“集群”拓扑中实现的主要麻烦。
• 相对于MyISAM，InnoDB有着很大的缺陷，而且几乎没有什么好处。(可以说，唯一的好处是减少了所需的磁盘空间。)

Answer 2

InnoDB中的特性称为自适应哈希索引，

是否使用散列索引取决于表的规模和查询频率，它是一种完全内部的策略，通常是脱离配置的。

https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html