具有哈希索引的 MySQL InnoDB 表

Question

我有一张这样的 table 。

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 上的索引，并且在 key stuff 中写着索引的名称!!

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

Answer 1

InnoDB 默默地将“HASH”更改为“BTree”。 BTree 索引的功能与 HASH 的功能相同，而且更多。还是您认为有充分的理由需要 Hash？

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

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

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

• 复制(3.xx？)
• 事务(在 4.0 中添加 InnoDB)(MyISAM 有LOCK TABLES，但这还不够。)
• information_schema(4.1？)(与各种 SHOW 命令相比)注意:8.0 使用“数据字典”对它进行了大修)
• 字符集和排序规则 (4.1)(对比“latin_swedish_ci”，这对实现者来说已经足够好了。)
• 存储例程(与客户端代码对比)(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)
INDEXes 中的
• DESC (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 Cluster)
• 静态加密(8.0？)

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

• 多线程执行(如果您受 I/O 限制，则无用)(8.0 中的用例很少)
• HASH 索引(和其他类型)(MariaDB 10.4，仅适用于TEXT/BLOB 上的UNIQUE)
• 用于PARTITIONing 的全局UNIQUE 和FOREIGN KEY。 (并不是说分区很有用。)
• 与标准和其他供应商的语法兼容性更高(MariaDB 在这方面做得更好)

与此同时，有些东西正在消失(或者已经消失——无论是在 MariaDB 还是 MySQL 中)

• 为各种计算机编译——例如 Atari
• 查询缓存——用于基准测试很方便，但在生产环境中并不是很有用。在任何“集群”拓扑中实现都是一个主要的麻烦。
• MyISAM 相对于 InnoDB 有很大的缺陷，而且几乎没有什么好处。 (可以说，唯一的好处是所需的磁盘空间更少。)