数据库为啥用哈希索引

数据库中使用哈希索引（Hash Index），主要是因为它在等值查询（=）场景下极快，能在O(1) 时间复杂度内定位数据。下面从原理、优点、局限性和适用场景几个方面来解释。

一、哈希索引的基本原理

哈希索引的核心是 哈希表（Hash Table）：

1. 对索引列的值计算哈希值（如 hash(key)）
2. 用哈希值定位到对应的 哈希桶（bucket）
3. 桶中存放指向实际数据行的指针

查询过程类似：

key → hash(key) → bucket → data pointer → data

二、为什么数据库要用哈希索引？

✅ 1. 等值查询性能极高

对于 精确匹配查询：

SELECT * FROM user WHERE id = 1001;

哈希索引在理想情况下是 O(1)，速度远快于 B+ 树索引的 O(log n)。

✅ 2. 实现简单、查询路径短

• 不需要像 B+ 树那样进行多次比较
• 没有树的高度问题
• 非常适合内存数据库或内存临时结构

✅ 3. 适合内存型数据库

哈希索引非常适合放在内存中：

• Redis
• MemSQL / VoltDB
• MySQL Memory 引擎

因为：

• 不需要顺序访问
• 没有磁盘页结构限制
• 内存随机访问成本低

✅ 4. 临时结构或隐式优化

数据库在执行 SQL 时，内部也会用到哈希思想：

• GROUP BY
• DISTINCT
• JOIN（Hash Join）
• 临时表

即使不显式建哈希索引，数据库内部仍然广泛使用哈希结构。

三、哈希索引的致命缺点（为什么不是万能）

❌ 1. 不支持范围查询

WHERE age > 20
WHERE salary BETWEEN 5000 AND 10000

哈希索引 完全无法支持，因为：

• 哈希值打乱了原始顺序
• 没有顺序性

❌ 2. 不支持排序和前缀匹配

ORDER BY col
LIKE 'abc%'

哈希索引：

• 无法保证顺序
• 无法利用前缀

❌ 3. 哈希冲突问题

不同的 key 可能映射到同一个桶：

• 需要解决冲突（链表 / 开放寻址）
• 冲突严重时性能退化

❌ 4. 不适合磁盘存储

• 哈希表扩容成本高
• 磁盘随机 IO 代价大
• 不适合高并发写入场景

所以主流磁盘数据库默认不用哈希索引做主键索引。

四、和 B+ 树索引的对比

五、数据库中的典型使用场景

✅ 1. MySQL

• Memory 引擎：支持显式哈希索引
• InnoDB：不支持用户建哈希索引，但内部有自适应哈希索引（AHI）

✅ 2. PostgreSQL

• 支持 USING hash 索引
• 多用于等值查询

✅ 3. 内存数据库 / KV 存储

• Redis
• RocksDB（部分场景）
• 临时表、中间结果

六、一句话总结

数据库用哈希索引，主要是为了在等值查询场景下获得极致性能，尤其适合内存环境，但由于不支持范围和排序，无法替代 B+ 树索引。

如果你愿意，我也可以：

• 用一张图解释哈希索引
• 对比 MySQL InnoDB 的 Adaptive Hash Index
• 结合具体 SQL 分析该不该用哈希索引