问题场景

日志表常见查询是“取某段时间内的记录”，例如按 created_at 过滤最近几分钟或某一天的数据。若在 created_at 上建立普通 B-tree 索引，索引会为大量行保存键值，索引体积和写入维护成本随数据量增长。BRIN（Block Range Index）保存的是一段数据块范围内的最小值和最大值摘要，更适合索引列与物理存储顺序相关的大表。

BRIN 的关键前提是数据在物理上大致有序。日志通常按时间追加写入，created_at 与插入顺序相关，因此范围查询可以先排除大量不可能命中的块范围，再回到堆表过滤。BRIN 不保存精确行位置，查询仍需 recheck，不能把它当作 B-tree 的通用替代。

最小可运行示例

以下 SQL 用于演示建表、按 created_at 递增插入、创建 BRIN 与 B-tree 索引、比较大小并查看执行计划。BRIN 自 PostgreSQL 9.5 起提供，具体语法请以实际使用版本文档为准。示例数据量使用占位值 300000，可按环境调整。

CREATE TABLE app_log (
    id bigserial PRIMARY KEY,
    created_at timestamptz NOT NULL,
    level text NOT NULL DEFAULT 'INFO',
    message text NOT NULL
);

INSERT INTO app_log (created_at, level, message)
SELECT
    TIMESTAMPTZ '2024-01-01 00:00:00+00'
      + (g::text || ' seconds')::interval,
    'INFO',
    'log line ' || g
FROM generate_series(1, 300000) AS g;

ANALYZE app_log;

CREATE INDEX app_log_created_at_brin
ON app_log USING brin (created_at)
WITH (pages_per_range = 32);

CREATE INDEX app_log_created_at_btree
ON app_log USING btree (created_at);

SELECT
  pg_size_pretty(pg_relation_size('app_log_created_at_brin')) AS brin_size,
  pg_size_pretty(pg_relation_size('app_log_created_at_btree')) AS btree_size;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at, level
FROM app_log
WHERE created_at >= TIMESTAMPTZ '2024-01-01 00:00:00+00'
  AND created_at <  TIMESTAMPTZ '2024-01-01 00:05:00+00';

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at, level
FROM app_log
WHERE created_at >= TIMESTAMPTZ '2024-01-01 00:00:00+00'
  AND created_at <  TIMESTAMPTZ '2024-01-01 12:00:00+00';

DROP INDEX app_log_created_at_brin;

CREATE INDEX app_log_created_at_brin
ON app_log USING brin (created_at)
WITH (pages_per_range = 128);

ANALYZE app_log;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at, level
FROM app_log
WHERE created_at >= TIMESTAMPTZ '2024-01-01 00:00:00+00'
  AND created_at <  TIMESTAMPTZ '2024-01-01 00:05:00+00';

示例中可观察三点：第一，pg_relation_size 可直接比较两个索引的物理大小；第二，EXPLAIN 的 cost 是估算值，应结合 BUFFERS 和 Rows Removed by Index Recheck 判断实际访问块数与过滤损耗；第三，pages_per_range 从 32 改为 128 后，摘要粒度变粗，索引通常更小，但每次命中的块范围更大，窄范围查询的 recheck 可能增加。不要用单次示例输出替代基准测试。

运行方法

将 SQL 保存为 brin_demo.sql，在测试库执行：

psql -d your_db -f brin_demo.sql

执行前确认表名不与现有对象冲突。插入 30 万行只是演示，生产环境应使用维护窗口或评估 CREATE INDEX CONCURRENTLY 等在线变更方式，并避免直接在生产执行 DROP INDEX。建索引后运行 ANALYZE，让优化器获得统计信息。对比窄范围与宽范围查询时，关注扫描方式、读取块数、recheck 行数，而不是只看总 cost。

边界与限制

BRIN 适合大表、索引列与物理顺序相关、以范围扫描为主且可接受 recheck 的场景。日志、时序追加数据是典型候选。若数据乱序插入，或同一块范围内 created_at 跨度很大，BRIN 摘要的选择性会下降，可能退化为扫描大量块。

小表、点查、极窄范围查询通常更适合 B-tree。B-tree 能精确到行，索引扫描目标更集中；BRIN 索引虽小，但可能读取更多数据块。pages_per_range 需要权衡：值小则摘要更细、索引更大；值大则索引更小、过滤损耗可能更高。默认值可作起点，最终应结合数据分布和查询范围验证。

另外，BRIN 需要 recheck，查询条件仍要过滤；频繁更新索引列可能使摘要范围变宽，降低效果。多列 BRIN 也不等同于 B-tree 复合索引的精确匹配能力。实际选型应同时比较索引大小、写入维护成本、执行计划和缓冲区访问，避免只凭索引体积下结论。