第 08 章：B-Tree 与 HASH

zjc 于 2026-01-08 发布

这是《PostgreSQL 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 B-Tree 是 PostgreSQL 默认索引，适合等值、范围和排序。HASH 索引只适合等值，适用面较窄。

CREATE INDEX idx_orders_user_created
ON orders(user_id, created_at DESC);

B-Tree 适合：

不适合：

CREATE INDEX idx_orders_status_created
ON orders(status, created_at);

有效：

WHERE status = 'PAID'

WHERE status = 'PAID'
  AND created_at > now() - interval '1 day'

ORDER BY created_at

较弱：

WHERE created_at > now() - interval '1 day'

复合索引遵循左前缀原则。设计顺序通常是等值列在前、范围列在后。

CREATE INDEX idx_orders_cover
ON orders(user_id, created_at)
INCLUDE (amount, status);

INCLUDE 列不参与排序，可用于 Index Only Scan。是否能只扫索引还取决于可见性映射和 vacuum 状态。

只索引活跃订单：

CREATE INDEX idx_orders_open
ON orders(created_at)
WHERE status IN ('CREATED', 'PAID');

适合状态少部分占比、查询条件固定的场景。

CREATE INDEX idx_users_lower_email
ON users(lower(email));

查询必须使用相同表达式：

SELECT *
FROM users
WHERE lower(email) = 'alice@example.com';

适合函数值高频查询，但增加写入成本，并要求函数语义稳定。

CREATE UNIQUE INDEX uq_orders_order_no
ON orders(order_no);

部分唯一索引常配合软删除：

CREATE UNIQUE INDEX uq_users_email_active
ON users(email)
WHERE deleted_at IS NULL;

CREATE INDEX idx_users_email_hash
ON users USING HASH (email);

只有纯等值、基数高且 B-Tree 空间压力大时才值得评估 HASH。

查看索引使用：

SELECT
    schemaname,
    relname,
    indexrelname,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch
FROM pg_stat_user_indexes
ORDER BY idx_scan;

重建：

REINDEX INDEX idx_orders_user_created;
REINDEX TABLE CONCURRENTLY orders;

删除索引前观察完整业务周期，避免只看低峰一天。

索引不是越多越好。每个索引都应能对应明确查询。

B-Tree 覆盖大多数等值、范围和排序需求。复合索引注意左前缀，表达式和部分索引能解决特殊模式，HASH 只适合纯等值。索引设计要同时考虑查询收益和写入代价。