RDS MySQL InnoDB 引擎表索引类型更改为 Hash 后无效的原因
1. 问题描述
MySQL 包含的索引类型主要包括 Btree、Hash、FullText 和 Rtree，经常使用的主要是 Btree 和 Hash 两种索引。
通过 DMS 登录 RDS 实例后，执行 DDL 语句可以在 InnoDB 引擎表上创建 Hash 类型的索引，如图：
drop table if exists auth_order;
create table auth_order (
id smallint not null comment '主键',
member_id varchar(30) not null comment '会员id',
name varchar(100) not null comment '名称',
primary key (id),
key auth_mem_name (member_id) using hash
) engine=innodb default charset=utf8 comment='会员信息';
可以查看到该表中的索引 auth_mem_name 是 Hash 索引。
但是在 DMS 中查看表结构的时候可以查看到下图，可以查看到该索引的类型仍然是 Btree 类型。
2. 问题原因
由于 MySQL InnoDB 引擎不支持 Hash 索引，而 MySQL 服务层是有 Hash 索引选项的，因此建表语句可以使用子句 Using Hash，而实际创建的索引类型仍然是 Btree 类型的索引。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
确实，您遇到的情况是由于InnoDB存储引擎的特性所导致的。InnoDB是MySQL中最常用的存储引擎之一，它以支持事务处理、行级锁定和外键约束而著称。然而，InnoDB引擎实际上并不支持Hash索引；它主要使用B-Tree索引结构来优化查询性能。
在您的示例中，尽管DDL语句中指定了USING HASH来尝试创建哈希索引，但因为InnoDB引擎的限制，该指令被MySQL服务层忽略，实际创建的仍然是B-Tree索引。这解释了为什么在DMS（数据管理服务）中查看表结构时，索引类型显示为Btree而非预期的Hash。
解决方案与建议：
-
接受并利用B-Tree索引： 对于大多数应用场景，InnoDB的B-Tree索引已经足够高效，特别是在处理范围查询、排序和唯一性约束方面表现优秀。因此，除非有特别的需求指向其他存储引擎（如MyISAM支持Hash索引），否则继续使用B-Tree索引是推荐的做法。
-
考虑使用其他技术优化： 如果您原本希望通过Hash索引来加速等值查询，可以评估是否可以通过优化查询、增加适当的覆盖索引或调整数据库参数来达到相似的性能提升效果。
-
更换存储引擎： 如果特定场景下Hash索引对于性能至关重要，且InnoDB的其他特性不是必须的，可以考虑将表的存储引擎改为支持Hash索引的MyISAM。但需要注意的是，这样做会失去事务处理、行级锁等InnoDB提供的高级功能，需要权衡利弊。
-
使用Redis等内存数据库辅助： 对于极度频繁的简单键值对查询，也可以考虑将部分热数据迁移到Redis这类内存数据库中，利用其内置的哈希数据结构来加速查询。
综上所述，虽然直接在InnoDB表上创建Hash索引不可行，但通过上述方法仍然可以有效优化数据库性能，满足应用需求。
