在PostgreSQL执行一条带有过滤条件的SQL时，优化器会在多种扫描路径中挑选预计代价最低的一种。其中索引扫描（Index Scan）和位图扫描（Bitmap Heap Scan）是经常被拿来对比的两种借助索引的访问方式。它们并不是互斥的两种技术，而是针对不同数据分布和返回量所做的不同权衡。搞清优化器在什么情况下从索引扫描切到位图扫描，是排查慢查询和建立合理索引的基础。
两种扫描方式的基本执行原理
索引扫描的工作方式相对直观。优化器首先进入索引结构（如B树），从根节点向下定位到满足条件的索引项，拿到对应的堆元组地址（TID），然后直接到堆表中读取该行数据。如果查询还有第二个索引可用，PostgreSQL也支持Index Scan配合其他过滤，但核心特征是每命中一个索引项就立即去堆表取一次行。这种方式的优势是只要索引能精确过滤，堆表访问量就等于返回行数，不会读取无关块。
当符合条件的索引项很多，且这些项指向的堆表块在物理上非常分散时，索引扫描会产生大量随机IO。磁盘臂需要不断跳动到不同页面，尤其当effective_cache_size较小、缓存命中率低时，性能会急剧下降。此时优化器可能改用位图扫描：先通过索引求出一个位图，每一位代表一个堆表页是否被命中，多个索引还可以做位图AND或OR；随后按照堆表物理顺序一次性把需要的页读上来，再在内存中逐行过滤。这样把随机读转化成了近似顺序读。
可以用下面这段伪代码理解两者的差异。索引扫描像是边查边取，位图扫描则是先圈范围再批量取。
-- 索引扫描逻辑示意 FOR tid IN SELECT ctid FROM user_idx WHERE age > 20 LOOP FETCH heap_page WHERE ctid = tid; -- 随机IO END LOOP; -- 位图扫描逻辑示意 bitmap = BUILD_BITMAP FROM user_idx WHERE age > 20; FOR page IN heap_pages ORDER BY physical_seq WHERE bitmap HAS page LOOP FETCH page SEQUENTIALLY; -- 顺序IO FILTER rows IN page; END LOOP;
优化器选择扫描路径的成本计算因素
PostgreSQL优化器依靠统计信息和代价参数来估算每种路径的总成本。对于索引扫描，主要成本来自索引查找和逐行堆表访问。随机页的代价由random_page_cost表示，通常默认是4.0，而顺序页代价seq_page_cost是1.0。如果索引命中行数多且分散，random_page_cost乘以访问次数会迅速推高总代价。相反，位图扫描的堆表访问被视作顺序读，代价更低，但需要额外构造和遍历位图，还有内存开销。
另一个关键参数是effective_cache_size，它告诉优化器有多少内存可用于缓存数据。如果该值设得大，优化器认为堆表和索引更可能已在缓存中，随机IO的真实代价下降，于是更倾向于索引扫描；如果设得小，随机读被认为更昂贵，优化器偏向位图扫描。此外，返回行数预估来自表的统计信息，若ANALYZE不及时，行数估计偏差会让优化器误选路径。
我们通过一个对比表来看不同场景下的倾向：
| 场景特征 | 常见选择 | 原因 |
|---|---|---|
| 等值查询，返回行极少 | 索引扫描 | 堆表访问少，随机IO可控 |
| 范围查询，返回行多且分散 | 位图扫描 | 随机IO合并为顺序IO更划算 |
| 表数据与索引高度聚簇 | 索引扫描 | 相邻TID指向相邻页，随机性低 |
如何利用该机制进行索引与参数调优
在实践中，如果我们发现本应很快的查询却走了位图扫描且性能差，可以先检查是否为统计信息过期。执行ANALYZE命令更新分布数据，往往就能让优化器重新选回索引扫描。另外，使用CLUSTER命令按照索引顺序物理重排表，可以提升索引扫描的局部性，使随机IO大幅减少，这对时间戳类范围查询尤其有效。
当查询经常使用多个过滤条件，例如WHERE status = 1 AND create_time > '2023-01-01'，建立复合索引能让位图扫描阶段就完成两个条件过滤，生成更小的位图。我们也可以临时用SET enable_indexscan = off来观察优化器在位图扫描下的计划代价，辅助判断参数是否合理。需要注意的是，生产环境不要长期关闭某种扫描，仅用于调试。
最后，合理设置random_page_cost与effective_cache_size对云上SSD实例非常关键。SSD的随机读延迟远低于机械盘，可将random_page_cost调至接近1.1到2.0之间，让优化器更公平地看待索引扫描。同时调大effective_cache_size到机器内存的半数以上，使缓存假设更贴近现实，避免不必要的位图开销。通过这些手段，才能让PostgreSQL在索引扫描与位图扫描之间做出最符合业务实际的选择。
PostgreSQLindex_scanbitmap_scan修改时间：2026-08-16 09:28:14