HASH索引通过哈希函数将索引列值映射为哈希码，以O(1)时间复杂度实现等值查询；InnoDB通过自适应哈希索引自动优化，MEMORY引擎支持显式创建HASH索引；但其不支持范围查询、排序和前缀匹配，仅适用于精确查找场景。
MySQL中的HASH索引主要依赖于哈希表结构来实现快速的数据查找。它适用于等值查询（即使用=或操作符），但不支持范围查询、排序或前缀匹配。HASH索引在特定场景下效率极高，但使用受限。
MySQL HASH索引如何工作
HASH索引基于对索引列的值进行哈希计算，将计算出的哈希值存储在哈希表中，并指向对应的数据行位置。当执行查询时，MySQL会对查询条件中的值再次进行相同的哈希运算，然后在哈希表中快速定位到对应的存储位置，从而直接访问目标数据行。
其核心流程如下：
- 对索引列的值应用哈希函数，生成固定长度的哈希码
- 将哈希码作为键，存储指向实际数据行的指针
- 查询时对搜索条件进行相同哈希处理，通过查表快速定位
由于哈希函数的特性，这种查找方式平均时间复杂度为O(1)，非常高效。
InnoDB与MEMORY引擎中的HASH索引差异
并非所有存储引擎都支持显式创建HASH索引。InnoDB和MEMORY对HASH索引的支持方式不同：
- InnoDB引擎默认使用B+树索引，但它会自动为某些频繁使用的等值查询构建自适应哈希索引（Adaptive Hash Index），这是内部机制，不可手动控制
- MEMORY引擎支持显式创建HASH索引，在建表时可通过
USING HASH指定，适合做临时表的高速等值查找
例如MEMORY表中定义HASH索引：
CREATE TABLE temp_lookup (
id INT,
name VARCHAR(50),
INDEX name_idx (name) USING HASH
) ENGINE=MEMORY;
HASH索引的限制与适用场景
HASH索引虽然查找快，但有明显局限性：
- 仅支持等值比较，不支持
>、、<code>BETWEEN这类范围查询 - 无法用于ORDER BY排序，因为哈希后顺序被打乱
- 不支持最左前缀原则，必须使用完整索引列
- 存在哈希冲突可能，尽管良好哈希函数可降低概率
适合场景包括：精确匹配的查找，如用户ID、状态码、唯一标识符等短字段的等值过滤。
何时选择HASH索引
在MEMORY引擎中，若查询模式主要是“列 = 值”，且数据量适中，使用HASH索引能显著提升性能。而在InnoDB中，无需手动干预，系统会根据访问模式自动判断是否启用自适应哈希索引。
建议在以下情况考虑使用HASH索引：
- 频繁执行
SELECT ... WHERE key = 'value' - 数据变更较少，避免哈希表频繁重建
- 内存充足，尤其是使用MEMORY表时
基本上就这些。HASH索引不是通用解决方案，理解其原理有助于在合适场景下发挥最大效能。
