PostgreSQL查询未调用已创建的BRIN索引是什么原因

不属于操作配置错误，核心是BRIN索引的选型不符合当前数据特征：

• BRIN即块范围索引，工作机制是按表的物理存储连续块（默认每128个块为一个统计单元）存储被索引列的最小值、最大值，查询时靠这个元信息直接跳过完全不包含目标值的块范围，只有当被索引列的取值和表物理存储顺序高度相关时，才能发挥过滤效果。
• 你的测试数据里sensor_id是通过random()随机生成的，完全无排序规律：每个统计块内的sensor_id最小值接近0、最大值接近100000，查询sensor_id=10时，BRIN索引会判定几乎所有块都可能包含目标值，走BRIN索引不仅要扫描几乎全量数据块，还要额外承担索引读取、位图计算的开销，总成本比直接顺序扫描更高，优化器自然会选择成本更低的顺序扫描。

根据你的实际场景选择对应方案即可：

• 场景1：仅为测试BRIN索引功能
  需要先让被索引列和表物理存储顺序对齐，执行以下命令：

  -- 按BRIN索引的列重排表的物理存储顺序
  CLUSTER Measure USING idxbrin_measure_sensor_id;
  -- 更新统计信息保证优化器成本估算准确
  ANALYZE Measure;
  

  操作完成后再执行查询，优化器就会选择BRIN索引，此时目标值仅集中在极少数物理块中，BRIN的过滤效率远高于全表扫描。
• 场景2：模拟真实业务写入
  如果业务中sensor_id本身就是随机写入、和物理存储顺序没有强相关性，BRIN索引本身就不适用这类场景，直接创建B-tree索引才是正确方案：

  -- 乱序数据的等值查询场景，B-tree索引的效率远高于BRIN
  CREATE INDEX idx_measure_sensor_id_btree ON Measure USING btree(sensor_id);
  

注意：BRIN索引的设计目标是服务时序表、日志表这类按顺序写入、被索引列（如自增ID、时间戳）与写入顺序强相关的超大表，靠极小的索引体积实现快速块过滤，从来不是B-tree索引的通用替代方案。就算你通过SET enable_seqscan = off;强制优化器走乱序数据上的BRIN索引，实际执行速度也会比顺序扫描更慢，优化器的选择是符合成本逻辑的，不存在功能bug。

内容的提问来源于stack exchange，提问作者Radim Bača