Hash索引适用于等值查询场景，从PostgreSQL 10起支持WAL和并行查询，具备崩溃恢复能力；其基于哈希表实现，查询复杂度接近O(1)，适合高并发精确匹配、UUID主键访问及缓存类key-value应用；相比B-tree，Hash索引不支持范围查询、排序或多列前缀匹配，但等值性能更优、体积更小；使用时需确保查询模式仅为“=”，避免未来扩展需求，并注意冲突与碎片问题，定期reindex以维持性能。
PostgreSQL 中的 Hash 索引虽然在过去版本中功能受限，但从 PostgreSQL 10 开始得到了显著增强，支持 WAL（Write-Ahead Logging）和并行查询，使其在特定场景下具备了实用价值。理解其机制和适用场景，有助于在实际应用中做出更合理的索引选择。
Hash 索引的基本机制
Hash 索引基于哈希表实现，通过哈希函数将索引键值转换为一个哈希码，然后将该码映射到索引页中的具体位置。这种结构决定了它只支持等值查询（=），不支持范围查询（如 、BETWEEN）或排序操作。
主要特点包括：
- 仅支持等值条件匹配，适合“key = value”类查询
- 查询性能稳定，通常为 O(1) 时间复杂度（理想情况下）
- 不记录完整的键值，只存储哈希值和原始值的引用，节省部分空间
- 支持 WAL 后，具备崩溃恢复能力，可靠性提升
- 不支持部分索引或表达式索引（某些版本有限支持）
适合的应用场景
由于 Hash 索引的特性，它适用于以下几类典型场景：
- 高并发等值查找：如用户登录系统中根据用户名或邮箱精确查找用户记录，这类操作频繁且只涉及“等于”判断，Hash 索引响应更快
- 大表的主键或唯一键等值访问：当主键不使用自增 ID 而是 UUID 或字符串时，若查询模式以精确匹配为主，可考虑使用 Hash 索引
- 缓存模拟场景：数据库被用作外部系统的缓存后端，通过 key-value 形式访问数据，Hash 索引能提供类似内存哈希表的访问效率
- 避免 B-tree 索引的深度遍历开销：对于短周期高频访问的小到中等规模表，Hash 索引可能比 B-tree 更快完成定位
与 B-tree 索引的对比
B-tree 是 PostgreSQL 默认且最通用的索引类型，支持范围扫描、排序、前缀匹配等，而 Hash 索引功能更为专一。
关键差异点：
- Hash 不支持
ORDER BY和>/查询，B-tree 支持 - Hash 在等值查询上通常更快，尤其在高基数列上
- B-tree 索引可被用于多列索引中的前导列范围查询，Hash 无法做到
- Hash 索引体积通常略小，但重建代价较高
使用建议与注意事项
尽管 Hash 索引已更可靠，但仍需谨慎使用：
- 仅在确认查询均为等值匹配时选用
- 避免在需要未来扩展查询类型的列上创建 Hash 索引
- 注意 Hash 冲突问题，虽然 PostgreSQL 使用链式处理，但极端情况会影响性能
- 定期执行
REINDEX可优化碎片和性能 - 监控
pg_stat_user_indexes判断实际使用效果
基本上就这些。Hash 索引不是万能替代方案，而是针对特定负载的优化工具。合理评估查询模式后再决定是否采用，才能发挥其最大价值。
