在MySQL的索引体系里，哈希索引是一种基于哈希表实现的特殊索引结构。它通过对索引列的值进行哈希函数运算，将结果映射到哈希桶中，从而在等值查询时达到接近常数级的时间复杂度。与常见的B树索引不同，哈希索引并不维护数据的有序性，因此在特定场景下有着截然不同的性能表现。
哈希索引的基本原理
哈希索引的核心在于哈希函数与哈希表的配合。当我们在一张使用哈希索引的表上执行等值查询时，存储引擎会先对查询条件中的索引列计算哈希值，然后直接定位到哈希表中对应的槽位，从中获取指向数据行的指针。由于哈希函数的分布特性，理想情况下每次查找只需一次哈希计算加一次指针跳转，避免了B树索引从根节点到叶子节点的多层遍历。
以Memory存储引擎为例，它原生支持哈希索引。当我们创建表并指定索引类型为HASH时，数据全部驻留内存，哈希表也建立在内存中。下面的代码展示了一个简单的Memory表哈希索引定义：
CREATE TABLE user_token ( token VARCHAR(64) NOT NULL, user_id INT NOT NULL, KEY USING HASH (token) ) ENGINE=MEMORY;
上述表中，token列上建立了哈希索引。当执行SELECT user_id FROM user_token WHERE token = 'abc123'时，引擎会对'abc123'计算哈希，迅速找到对应记录。不过要注意，哈希索引只存储哈希值和行指针，不保存字段原始值，因此无法用于覆盖索引扫描。
哈希冲突与应对方式
哈希函数并非完美，不同的索引值可能产生相同的哈希值，这就是哈希冲突。在MySQL的哈希索引实现中，通常采用链地址法处理冲突：同一个哈希槽位以链表形式串联多个指向不同数据行的指针。当冲突较多时，查找需要从槽位遍历链表来比对真实值，性能会有所下降。
我们可以通过下面的伪代码理解冲突处理过程：
// 简化版哈希索引查找逻辑
int slot = hash_function(key) % bucket_count;
Node* cur = buckets[slot];
while (cur != NULL) {
if (cur->row->key == key) { // 比对真实值
return cur->row;
}
cur = cur->next;
}
return NULL;
从代码可见，即便哈希值相同，仍然需要一次真实值的比较才能确认数据。因此在设计索引时，应尽量选择离散度高的列，避免大量重复值导致哈希碰撞频繁。此外，若业务使用过长字符串做哈希索引，可考虑只对其前缀计算哈希，但要注意前缀重合带来的误判风险。
InnoDB自适应哈希索引
虽然InnoDB默认使用B树索引，但它提供了一种称为自适应哈希索引（Adaptive Hash Index，简称AHI）的机制。当InnoDB发现某些索引页被频繁以等值方式访问时，会在内存中基于B树页的键值自动构建哈希索引，以加速后续的等值查询。
自适应哈希索引完全由引擎内部管理，用户无法通过DDL语句直接创建，但可以通过参数控制开关：
-- 查看自适应哈希索引状态 SHOW VARIABLES LIKE 'innodb_adaptive_hash_index'; -- 关闭自适应哈希索引 SET GLOBAL innodb_adaptive_hash_index = OFF;
开启AHI后，在高频主键等值查询或唯一索引查找的场景中，往往能看到明显的延迟下降。然而，如果系统存在大量并发写入或范围查询，AHI的维护开销可能抵消其收益，此时关闭反而能提升整体吞吐。DBA应结合具体业务压测决定是否启用。
哈希索引的适用边界与局限
哈希索引的最大优势是等值查询极快，但它不支持范围查询、排序、前缀匹配和覆盖扫描。例如对带有WHERE age > 20的语句，哈希索引完全无效，只能退化为全表扫描或由优化器改走其他B树索引。此外，哈希索引也无法用于避免排序操作，因为数据在哈希表中是无序存放的。
在联合索引方面，哈希索引会将多个列值合并计算为一个哈希值，因此只有当查询条件包含所有联合列做等值比较时才生效，无法像B树那样支持最左前缀匹配。下面的表格对比了两者主要差异：
| 特性 | 哈希索引 | B树索引 |
|---|---|---|
| 等值查询 | 极快 O(1) | 较快 O(log n) |
| 范围查询 | 不支持 | 支持 |
| 排序与分组 | 不支持 | 支持 |
| 最左前缀 | 不支持 | 支持 |
基于以上特点，哈希索引非常适合会话令牌校验、内存配置表读取、以及等值连接键等场景。在这些场景中，我们可以将热点小表放入Memory引擎并建哈希索引，或依赖InnoDB的AHI来加速。对于综合查询需求复杂的业务表，仍应以B树索引为主，将哈希索引作为特定路径的补充手段。
实践中的创建与使用建议
如果直接使用Memory引擎建表，可显式声明USING HASH；若使用InnoDB，可观察慢查询日志中高频的等值检索，尝试通过调优AHI参数来获取收益。在设计哈希索引列时，应避免对频繁更新的列建哈希索引，因为每次更新都可能需要重新计算哈希并调整哈希表结构，带来额外写放大。
下面给出一个在用户鉴权场景中利用Memory表加哈希索引的示例，其中包含写入与查询：
-- 创建内存鉴权表
CREATE TABLE auth_cache (
session_id VARCHAR(48) NOT NULL,
uid INT NOT NULL,
expire_ts BIGINT NOT NULL,
PRIMARY KEY USING HASH (session_id)
) ENGINE=MEMORY;
-- 写入会话
INSERT INTO auth_cache VALUES ('sess_888', 1001, 1700000000);
-- 高频等值查询
SELECT uid FROM auth_cache WHERE session_id = 'sess_888';
该方案将鉴权链路从磁盘B树查找转为内存哈希定位，在万级QPS下能显著降低CPU与延迟。但需要配套清理过期会话的定时任务，防止内存无限增长。总体而言，理解哈希索引的运行机制与限制，才能在高性能MySQL架构中把它用在刀刃上。