BRIN索引适合物理上按时间大致有序的时序表，否则查询可能退化为全表扫描；其空间仅为B-tree的1/100～1/50，但查询延迟不稳定，等值查询通常更慢，且需定期INDEX_CLEANUP维护。

BRIN 索引适合「按时间顺序写入」的时间序列表吗？

适合，但有硬性前提：数据必须物理上按索引列（比如 created_at）大致有序。如果每天批量导入旧数据、或存在大量乱序写入（如补录上周日志），BRIN 的块范围映射会失效，查询可能退化成全表扫描。

• PostgreSQL 不会自动重排数据，CLUSTER 或 VACUUM FULL 才能强制排序，但代价极高，不适用于持续写入的时序表
• 写入吞吐不受影响，但查询性能波动大：有序段快，乱序段慢，且优化器容易低估成本
• 典型适用场景：IoT 设备每秒追加新记录、日志服务按小时分区并顺序入库

和 B-tree 相比，BRIN 在查询响应与磁盘占用上差多少？

BRIN 占用空间通常是 B-tree 的 1/100～1/50（例如 1TB 表，BRIN 索引可能仅 20MB），但响应延迟更不稳定：

• 范围查询（如 WHERE created_at BETWEEN '2024-01-01' AND '2024-01-07'）在数据有序时，BRIN 可跳过 90%+ 数据块，比 B-tree 略快；但若跨多个非连续时间段，BRIN 需检查更多范围元组，反而多 IO
• 等值查询（WHERE created_at = '2024-01-01 10:00:00'）几乎总是比 B-tree 慢——BRIN 无法直接定位，得先过滤块再逐行扫
• page_per_range 参数影响大：默认 128，设太小（如 16）会让索引膨胀，设太大（如 1024）则跳过率下降，建议从 64 开始压测

维护成本低 ≠ 零维护：哪些操作会悄悄拖垮 BRIN 效果？

VACUUM 不更新 BRIN 元数据，这是最大误区：

• UPDATE 或 DELETE 后，旧元组仍标记为有效范围，导致后续查询误判、扫描冗余块
• 长期运行后，pg_stat_all_indexes.idx_scan 增长但命中率下降，而 idx_tup_read / idx_tup_fetch 比值飙升（说明读得多、取得少）
• 必须定期执行 VACUUM (INDEX_CLEANUP) table_name（PG 14+）或重建索引：CREATE INDEX CONCURRENTLY ... 替换旧 BRIN
• 如果表启用了 fillfactor ，插入热点页分裂也会让局部有序性劣化，此时 <code>BRIN 收益快速衰减

什么时候该果断放弃 BRIN，切回 B-tree 或分区表？

当出现以下任一情况，就别硬撑：

• 查询条件经常含 ORDER BY ... LIMIT 且偏移量大（如分页查历史数据），BRIN 无法支持高效跳跃
• 表上有多个高频过滤字段（如 device_id, metric_type），单靠 created_at 的 BRIN 覆盖不足，复合索引又不被 BRIN 支持
• 使用 citus 或逻辑复制，BRIN 在分片或备库上行为不一致，排查成本远超收益
• 每天新增数据量 B-tree 索引总大小已可控，省去调参和监控负担更实际

BRIN 不是“省索引空间”的捷径，它是用可预测的写入模式，换一种更脆弱的查询加速方式。一旦物理顺序松动，修复手段比建索引本身还重。