mysql中可以显式添加哈希索引的场景仅限于memory存储引擎，1.创建memory表时通过using hash语法指定主键或辅助索引；2.对已有memory表使用alter table添加哈希索引。对于innodb等磁盘引擎，无法手动创建哈希索引，但其内部会自动管理自适应哈希索引（ahi）以优化频繁访问的数据。哈希索引适用于精确等值查询、无范围和排序需求、数据量小且稳定的内存表，具有o(1)的查找效率，但不支持范围查询、排序和前缀匹配，且存在哈希冲突和内存消耗等局限性。
MySQL中添加哈希索引，通常指的是针对MEMORY存储引擎的表，可以通过USING HASH语法来创建。对于InnoDB或MyISAM等磁盘存储引擎，MySQL并不直接提供显式的CREATE HASH INDEX语法让用户手动创建哈希索引。相反，InnoDB引擎内部会根据访问模式自动创建和管理一种称为“自适应哈希索引”（Adaptive Hash Index, AHI）的机制，来加速频繁访问的数据。哈希索引的使用场景主要集中在需要快速进行精确等值查找的场景，尤其是在数据量相对稳定且查询模式单一的内存表中。
解决方案
如果你是想在MEMORY表上创建哈希索引，语法非常直接。例如，你有一个名为lookup_table的MEMORY表，想要在id列上创建哈希索引：
CREATE TABLE lookup_table (
id INT NOT NULL,
value VARCHAR(255),
PRIMARY KEY (id) USING HASH
) ENGINE=MEMORY;
-- 或者在已有的MEMORY表上添加哈希索引
ALTER TABLE lookup_table ADD INDEX idx_value (value) USING HASH;这里USING HASH明确告诉MySQL为这个索引使用哈希算法。
但对于InnoDB或MyISAM表，你无法这样显式地添加哈希索引。InnoDB的自适应哈希索引是其存储引擎内部的一个优化，它会监控对索引页的访问模式，如果发现某些索引值被频繁访问，它就会在内存中为这些值创建哈希索引，以加速查找。这个过程是完全自动的，我们作为用户无法直接控制它的创建、删除或配置，也无法通过SHOW INDEXES命令看到它。它更像是一种内部的缓存机制，而不是一个我们能直接操作的数据库对象。
MySQL中哈希索引与B-Tree索引的主要区别是什么？
我个人觉得，理解这两者的根本差异，是选择索引策略的基石。哈希索引和B-Tree索引在结构、查询方式和适用场景上有着显著的不同。
首先是结构和查找机制。B-Tree索引是一种平衡树结构，数据是按顺序存储的。查找时，MySQL会从根节点开始，沿着树的分支向下遍历，直到找到目标数据。这个过程类似于在字典里查找单词，每次都能排除掉一半的可能，所以查找效率是O(logN)。而哈希索引则像是一个散列表，它通过对索引列的值计算哈希码，直接映射到数据行在存储中的物理位置。理论上，只要没有哈希冲突，哈希索引的查找速度是O(1)，也就是常数时间，非常快。
其次是查询类型支持。B-Tree索引由于其有序性，不仅支持精确等值查找（=），还非常擅长范围查询（>、、BETWEEN），以及排序（ORDER BY）和前缀匹配（LIKE 'abc%'）。因为数据是有序的，遍历一段范围的数据非常高效。哈希索引则完全不具备这些能力。它只能用于精确等值查找，因为它只知道某个值映射到哪个位置，而不知道这个值的前后是哪些值。所以，如果你需要WHERE price > 100这样的查询，哈希索引是无能为力的。
最后是存储和内存使用。B-Tree索引通常会占用更多的磁盘空间，因为它们需要存储树的结构和指向数据行的指针。在内存中，它们也需要维护整个树的结构。哈希索引在内存中通常表现为哈希表，对于MEMORY表来说，如果哈希冲突较少，它的内存效率可能很高。但如果冲突很多，每个哈希桶下挂的链表会变长，查找效率就会下降，并且可能需要更多的内存来存储这些链表。对于InnoDB的自适应哈希索引，它只在内存中存在，不持久化到磁盘，因此重启数据库后会重新构建。
什么时候应该考虑使用MySQL的哈希索引（或依赖其内部机制）？
说实话，对于InnoDB，我们能做的就是优化好B-Tree索引，然后把自适应哈希索引（AHI）的优化交给MySQL自己。但了解它的工作原理，能让我们更安心，知道某些查询为什么会突然变快。
具体到我们能控制的哈希索引，也就是MEMORY表的情况，主要考虑以下场景：
-
精确等值查找非常频繁：这是哈希索引的“主场”。如果你有一个表，绝大多数查询都是形如
SELECT * FROM table WHERE id = 123这种精确匹配，并且这个表的数据量不大，且经常被访问，那么哈希索引能提供极高的性能。 -
作为查找表（Lookup Table）：
MEMORY表通常被用作存储一些不经常变动、需要快速查找的配置信息、映射关系或枚举值。比如，一个存储国家代码和国家名称的表，或者一个存储错误码和错误描述的表。这些表的数据量通常不大，而且查询模式单一，就是根据ID或代码查找对应的描述。 - 无需范围查询和排序：如果你的业务逻辑对这个表完全没有范围查询、排序或者模糊匹配的需求，那么哈希索引的劣势就不会暴露出来。
对于InnoDB的AHI，我们虽然不能控制，但可以知道，当你的B-Tree索引上的某些热点数据行被反复访问时，AHI会尝试介入，在内存中为这些热点数据构建一个哈希索引，从而绕过B-Tree的遍历过程，直接定位到数据。这在OLTP（在线事务处理）系统中，对于那些高并发、重复查询的场景，能带来显著的性能提升。你不需要为此做任何额外配置，它是InnoDB引擎的智能优化。
MySQL哈希索引有哪些局限性或潜在的性能陷阱？
我见过不少开发者，一听说哈希索引快，就想当然地用，结果发现根本不是那么回事。了解它的短板，比只知道它的优点更重要。
哈希索引的局限性非常明显，而且这些局限性往往是导致性能问题的“陷阱”：
-
不支持范围查询：这是最致命的局限。
WHERE id > 100、WHERE name LIKE 'A%'、WHERE created_at BETWEEN '...' AND '...'这类查询，哈希索引完全无法使用。它只能处理=或IN操作。如果你在MEMORY表上创建了哈希索引，但执行了范围查询，MySQL会退化为全表扫描，性能会非常差。 -
不支持排序：哈希索引不存储有序信息，因此不能用于
ORDER BY子句。如果查询需要排序，即使有哈希索引，也需要额外的排序操作。 -
不支持前缀匹配：
LIKE 'abc%'这样的查询也无法利用哈希索引，因为它需要遍历前缀匹配的范围，而哈希索引无法提供这种能力。 - 哈希冲突的影响：当不同的键值经过哈希函数计算后得到相同的哈希码时，就会发生哈希冲突。哈希索引通常通过链表来解决冲突，这意味着在发生冲突的情况下，查找效率会从理想的O(1)退化到O(N)，其中N是冲突链表的长度。如果数据分布不均匀，或者哈希函数选择不当，可能导致某些哈希桶下的链表过长，从而严重影响性能。
-
内存消耗：对于
MEMORY表，哈希索引需要将整个索引结构加载到内存中。如果索引的列值非常多且唯一，或者哈希冲突严重导致链表过长，可能会消耗大量内存。一旦内存不足，可能会导致性能下降甚至系统不稳定。 -
非持久化（针对
MEMORY表）：MEMORY表的数据和索引都存储在内存中，这意味着MySQL服务重启后，数据和索引都会丢失。这使得MEMORY表不适合存储需要持久化的数据。 -
InnoDB自适应哈希索引的不可控性：虽然AHI是自动的性能优化，但它的工作原理和触发条件对用户是透明的。在某些高并发、高更新的场景下，AHI的维护成本可能会抵消其带来的收益，甚至可能导致性能抖动。我们无法手动关闭或调整它（只能通过innodb_adaptive_hash_index参数全局开启或关闭，但通常不建议关闭）。
