在PostgreSQL中，慢查询优化通常会先想到加B-tree索引、调大shared_buffers或者改写SQL。但当查询条件只有符号=的等值匹配时，B-tree未必是最优选择。Hash索引在PostgreSQL内置访问方法中存在已久，很长一段时间里它不可写WAL日志，数据库崩溃后需要重建，也不支持流复制，因此很多生产系统不敢使用。从PostgreSQL 10开始，Hash索引补齐了WAL、复制和恢复能力，后续版本又持续改善并发与膨胀控制，等值查询场景才重新回到视野。
一、Hash索引的存储结构与等值查找原理
理解Hash索引并不复杂。它把索引键值交给哈希函数计算出一个32位哈希值，再通过桶号定位到某个桶页。一个桶页内可以存放多条索引元组，如果桶页写满，就会扩展溢出页，形成链式结构。与B-tree不同，PostgreSQL的Hash索引只保存哈希值和行指针，不保存原始索引键值。这意味着等值查询可以快速定位到桶，但还必须回表取出原始行，并再次比较索引列值，才能确认没有发生哈希碰撞。
B-tree的等值查找则走完全不同的路径。B-tree是平衡多路搜索树，查找一个键值时需要从根页开始，逐层比较键值大小，最终定位到叶子页。树高度通常保持在2到4层，等值查询的I/O次数近似等于树高。对于较短的整型键，这个过程非常高效。但当索引键是很长的字符串或复合键时，每次比较的CPU成本会明显上升，索引页能容纳的条目数也会下降，树高和I/O都可能增加。Hash索引在这类场景下具有结构优势，因为无论键值多长，参与桶定位的始终是固定长度哈希值。
可以通过系统表查看PostgreSQL内置的索引访问方法。下面SQL可以确认hash访问方法是否已经安装并可用：
SELECT amname, amhandler
FROM pg_am
WHERE amname IN ('hash', 'btree');
查询结果中看到hash和btree两行，说明数据库已经支持两种索引类型。实际创建索引时，只要在CREATE INDEX语句中通过USING子句指定hash即可。
二、Hash索引与B-tree的等值查询性能对比
单从等值查询角度比较，Hash索引的桶定位通常是常数级操作。理想情况下，哈希函数计算出桶号后，只需读取一个桶页，再加上堆表回表，就完成了整条查询路径。B-tree则至少需要访问2到4个索引页。对于百万行以上的大表，B-tree高度可能达到3层或4层，等值查询的索引访问成本高于Hash索引。
不过Hash索引的常数级操作并不是没有代价。哈希冲突会导致多个不同键值落入同一个桶，当桶页空间耗尽时，需要沿溢出页链继续查找。如果某个键值出现频率极高，或者索引列数据分布严重倾斜，溢出页链可能变得很长，等值查询性能会从接近O(1)退化为接近顺序扫描部分溢出页。因此在设计索引前，应该先查看目标列的唯一值数量和数据分布。
为了对比两种索引，可以在测试表中分别建立Hash索引和B-tree索引：
CREATE TABLE orders (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
order_no text NOT NULL,
customer_id bigint NOT NULL,
created_at timestamptz NOT NULL
);
INSERT INTO orders (order_no, customer_id, created_at)
SELECT 'ORD-' || g,
(g % 100000)::bigint,
now() - (g || ' seconds')::interval
FROM generate_series(1, 500000) AS g;
CREATE INDEX idx_orders_customer_hash
ON orders USING hash (customer_id);
CREATE INDEX idx_orders_customer_btree
ON orders USING btree (customer_id);
ANALYZE orders;
然后可以查看两个索引的物理大小。通常Hash索引因为只存哈希值，体积会比B-tree小，尤其在索引键较长时差异更明显：
SELECT c.relname AS index_name,
am.amname AS access_method,
pg_size_pretty(pg_relation_size(c.oid)) AS index_size
FROM pg_class c
JOIN pg_am am ON c.relam = am.oid
WHERE c.relname IN ('idx_orders_customer_hash', 'idx_orders_customer_btree');
大小差异只是参考，真正的性能要看执行计划中的I/O指标。可以使用EXPLAIN命令分别观察两条查询在相同条件下的访问路径。
三、创建Hash索引并验证等值查询生效
创建Hash索引的语法与B-tree几乎一致，差别只有USING hash。对于已经存在B-tree索引的表，临时增加一个Hash索引不会影响原有查询，优化器会根据成本模型自动选择它认为代价更低的索引。如果想让优化器优先考虑Hash索引，可以在会话中关闭顺序扫描和B-tree相关的部分参数进行对比验证。
例如下面的查询强制关闭顺序扫描，让优化器在可用索引中做选择：
SET enable_seqscan = off; EXPLAIN (ANALYZE, BUFFERS, COSTS ON) SELECT order_no, created_at FROM orders WHERE customer_id = 8888;
执行计划中如果出现Index Scan using idx_orders_customer_hash，就说明查询走了Hash索引。需要注意的是，即使Hash索引可用，优化器也不一定必然选择它。如果B-tree索引更小，或者统计信息更新不及时，执行计划仍可能落在B-tree上。因此对比时建议分别删除其中一个索引，或者使用pg_hint_plan等工具强制指定计划形状，但生产环境更推荐通过真实负载观察稳定表现。
Hash索引的维护成本也需要纳入考量。由于它不保留原始键值，删除和更新操作需要重新计算哈希值并清理对应桶项。频繁更新、删除的表可能产生溢出页膨胀，导致Hash索引体积变大，查询性能下降。对这类表应定期执行REINDEX或使用pg_repack等工具重建索引：
REINDEX INDEX idx_orders_customer_hash;
从PostgreSQL 10开始，Hash索引已经支持WAL日志、流复制和时间点恢复，不再像旧版本那样崩溃后必须重建。这一改变使得Hash索引可以进入生产环境，但使用前仍应确认主备复制链路和备份恢复流程已经覆盖该索引。
四、Hash索引的适用边界与避坑建议
Hash索引最重要的限制是它只支持等值比较。也就是说，WHERE条件中的=、IN、IS DISTINCT FROM等场景可能用到Hash索引，而BETWEEN、大于号、小于号、ORDER BY、MIN和MAX等操作都无法使用。因为哈希值本身不保留键值顺序信息，数据库无法从桶页中判断哪些键更大或更小。
以下场景不建议使用Hash索引：
- 需要创建主键、唯一约束或外键的列，因为PostgreSQL内部使用B-tree实现这些约束。
- 查询包含范围筛选、排序、前缀匹配或LIKE条件。
- 希望直接从索引返回数据，避免回表的index-only scan场景。Hash索引不保存原始键值，无法支持仅索引扫描。
- 高并发写入且键值重复率很高的表，容易形成较长的溢出页链。
反过来，Hash索引适合下面这几类负载：
- 等值查询占比极高，没有排序和范围扫描需求。
- 索引键较长，例如长字符串、UUID的文本表示或复合键，B-tree体积和维护成本偏高。
- 索引大小敏感，希望通过减少索引页占用降低缓存压力。
- 表以批量加载和大量等值点查为主，删除和更新比例较低。
在实际优化慢查询时，不要把所有等值查询列都盲目替换成Hash索引。建议先用pg_stat_statements找到执行次数高、延迟明显的SQL，再对比测试环境中的执行计划和Buffer读取次数。Hash索引不是B-tree的完全替代品，它解决的是特定等值查询负载下的I/O和体积问题。一个合理的策略是：主键和唯一列保留B-tree，纯粹的查询过滤列如果只做等值匹配，可以尝试使用Hash索引，并在生产发布后持续监控索引膨胀和执行计划变化。这样既能发挥Hash索引的等值定位优势，又不会牺牲B-tree在范围查询和约束支持上的能力。
PostgreSQL慢查询优化Hash索引等值查询修改时间：2026-08-23 13:36:51