哈希索引仅支持等值查询，不支持范围查询、排序及部分索引匹配，存在哈希冲突且仅MEMORY引擎支持显式创建，适用于高频等值查询的内存表场景。
哈希索引在 mysql 中主要用于 MEMORY 存储引擎，InnoDB 也支持一种称为“自适应哈希索引”的特性，但不支持用户显式创建哈希索引。由于其底层实现机制，哈希索引存在较多使用限制，不适合所有查询场景。
只支持等值查询
哈希索引基于哈希表实现，通过哈希函数将键值转换为哈希码进行快速查找。这种结构决定了它仅适用于等值比较（如 =, <=>, IN()）。
例如：
-
select * FROM user WHERE id = 10;—— 可以高效使用哈希索引 -
SELECT * FROM user WHERE id > 10;—— 无法使用哈希索引
范围查询、排序（ORDER BY）、不等条件（>, <, BETWEEN 等）都无法利用哈希索引加速。
不支持最左前缀原则和部分索引匹配
哈希索引是对整个索引列的值进行哈希计算，因此必须使用完整的键值进行匹配。对于复合索引，不能只使用其中一部分列进行查询。
例如：
- 有一个复合哈希索引
(name, age) -
WHERE name = 'Tom'—— 无法使用该哈希索引（除非是完整匹配） - 必须写成
WHERE name = 'Tom' AND age = 25才能命中
这与 B+ 树索引支持最左前缀匹配的灵活性形成鲜明对比。
无法用于排序和避免排序操作
哈希索引存储的数据是无序的，因为哈希值打乱了原始数据的顺序。因此不能用于 ORDER BY 优化，即使查询中使用了索引列，仍需额外排序操作。
例如：
-
SELECT * FROM user WHERE id = 10 ORDER BY name;—— 无法通过哈希索引避免排序
如果需要排序能力，应选择 B+ 树索引。
存在哈希冲突问题
不同键值可能产生相同的哈希码，导致哈希冲突。虽然存储引擎会通过链表等方式处理，但在高冲突情况下，查询性能会显著下降，退化为扫描多个行。
尤其当哈希表容量不足或负载因子过高时，性能不稳定。MEMORY 表的哈希索引需要合理设置 MAX_ROWS 和 BUCKET_COUNT 来减少冲突。
仅 MEMORY 引擎支持显式创建
MySQL 中只有 MEMORY 存储引擎允许使用 using HASH 显式创建哈希索引。InnoDB 虽然有“自适应哈希索引”，但由系统自动管理，不能人为控制。
示例：
CREATE TABLE user ( id INT, name VARCHAR(50), INDEX USING HASH (id) ) ENGINE=MEMORY;
其他引擎如 InnoDB、MyISAM 不支持手动创建哈希索引。
基本上就这些。哈希索引适合高频等值查询、内存表场景，但灵活性差，使用时要特别注意其局限性。多数情况下，B+ 树索引更通用可靠。