Navicat中判断Bitmap Index Scan是否真正使用位图，需查看执行计划是否同时出现“Bitmap Index Scan on xxx_gin_idx”和“Bitmap Heap Scan”，若仅有前者则未真正消费位图；必须用EXPLAIN (ANALYZE, BUFFERS)验证缓冲区读取及Rows Removed by Index Recheck值。
Navicat里怎么看Bitmap Index Scan是否真在用位图
PostgreSQL 的 Bitmap Index Scan 不是“用了GIN索引就自动出现”的结果，而是优化器权衡后选择的执行路径。Navicat 的「解释」结果中若只显示 Bitmap Index Scan on idx_name，但没配 Bitmap Heap Scan，说明位图根本没被真正消费——这通常意味着结果集太小，优化器直接降级为 Index Scan 了。
必须加 EXPLAIN (ANALYZE, BUFFERS) 才能确认：
- 看
Buffers: shared hit=xxx read=yyy—— 如果read显著高于预期，说明位图合并阶段反复读取页面，可能因索引膨胀或缓存不足导致效率下降 - 对比
Rows Removed by Index Recheck：值越大（尤其接近总扫描行数），说明位图精度差，大量行需回表校验，常见于gin_trgm_ops索引上短字符串（如'ab'）分词失败 - 注意
Actual Total Time是否集中在Bitmap Heap Scan阶段：若占比超 70%，说明位图生成快但回表慢，大概率是表膨胀或random_page_cost设置过低误导优化器
为什么key列为空但执行计划却写了Bitmap Index Scan
这是 Navicat 显示逻辑的典型误导：key 列只反映 B-Tree 类索引的名称，对 GIN/GIST/Bitmap 索引不适用。PostgreSQL 原生 EXPLAIN 根本不往 key 字段填值，Navicat 却沿用 MySQL 的字段映射逻辑，硬塞了个 NULL。
别信 key，盯紧这两处：
- 执行计划文本里是否明确出现
Bitmap Index Scan on xxx_gin_idx或Bitmap Heap Scan—— 这才是真实依据 - 用
\d+ table_name在查询窗口查索引定义，确认方法是gin且操作符类匹配（如col gin_trgm_ops，不是默认的gin_default_ops） - 如果
Bitmap Index Scan后紧跟Filter: col @@ 'abc'::tsquery，说明实际走的是全文检索路径，和 trigram 无关
Bitmap Index Scan慢的三个隐藏原因
表面是“位图扫描”，根子常不在索引本身，而在数据组织或配置偏差：
-
pg_stat_all_indexes中n_tup_ins - n_tup_del差值过大（比如 > 表总行数 30%）：说明索引膨胀严重，VACUUM没跟上，位图需跳过大量无效项 -
work_mem设置过小（如 EXPLAIN ANALYZE 会显示Temporary file: ...，I/O 直接拉垮 - 查询条件含多个
OR或IN，但字段没建联合 GIN 索引：优化器被迫为每个值单独生成位图再OR合并，CPU 占用飙升，而 Navicat 的「解释」表格完全不体现这个开销
怎么验证Bitmap Index Scan比Index Scan更优
不能只看执行计划类型，要实测两者的 buffer 和 time 分布：
- 强制走普通索引：在查询末尾加
/*+ IndexScan(table_name idx_name) */（PostgreSQL 14+ 支持 hint，旧版需改写为子查询或禁用位图开关） - 临时关闭位图路径测试：
SET enable_bitmapscan = off;，再跑EXPLAIN ANALYZE，对比Shared Hit和Total Time - 关键判断点：当
Bitmap Heap Scan的Rows Removed by Index RecheckBuffers read 比Index Scan方案少 2 倍以上时，位图才真正赢了
复杂点在于，同一张表、同一个查询，在不同 work_mem 或数据分布下，位图可能从最优变成最差——别依赖一次分析定论，得结合 pg_stat_database 的 blks_read 趋势看长期表现。
