位图索引适合高重复率、低基数且常用于IN/= /AND/OR过滤的字段，如status、gender；但NULL过多或统计信息过期时会失效。
位图索引适合哪些字段？不是所有低基数都该建
位图索引真正起效的前提，是字段值重复率高、且查询常以 IN、=、AND、OR 组合过滤——比如 status（'active'/'inactive'/'pending'）、gender、is_deleted。但若字段虽只有 3–5 个取值，却存在大量 NULL（比如 80% 是 NULL），位图索引反而会膨胀严重，查询变慢。
常见错误现象：SELECT COUNT(*) FROM orders WHERE status = 'shipped' 走了全表扫描，明明 status 只有 4 个值；原因往往是统计信息过期，或该列上有函数包装（如 UPPER(status)），导致优化器弃用位图索引。
- 建索引前先查真实基数：
SELECT COUNT(DISTINCT status), COUNT(*) FROM orders，比值 - 避免在频繁更新的 OLTP 表上建位图索引——每次 DML 都要锁整块位图，极易阻塞
- Oracle 和 PostgreSQL（通过
bitmap index扩展）支持原生位图索引；MySQL 不支持，别被网上“MySQL 位图索引”误导
多个位图索引一起用，AND/OR 查询才快
单个位图索引效果有限，它的优势在于位向量按位运算：优化器能把 WHERE region = 'CN' AND is_paid = 'Y' 拆成两个位图，再做 BITAND，比 B-tree 索引嵌套循环快得多。但这个能力依赖优化器识别布尔组合的能力，不是写出来就自动生效。
使用场景：OLAP 中宽表上的多维筛选，比如用户画像分析中同时按 age_group、device_type、has_coupon 过滤千万级事实表。
- 确保查询条件里没有隐式类型转换，比如
status = 1（字段是字符串），会导致位图索引失效 - Oracle 中需开启
STAR_TRANSFORMATION_ENABLED=TRUE才能高效合并多个位图索引 - PostgreSQL 的
pg_btree不支持位图合并，得靠pg_trgm或物化视图替代，别硬套 Oracle 经验
位图索引会拖慢 INSERT/UPDATE，尤其并发写入时
位图索引本质是一堆压缩位向量，每行更新都要定位到对应位并修改，还可能触发位图块分裂。在高并发插入场景下，它比 B-tree 更容易出现 enq: TX - row lock contention 或 buffer busy waits。
性能影响明显的情况：ETL 每小时批量插入百万订单，同时有位图索引在 order_type 上——插入吞吐可能下降 30% 以上，且长事务更容易卡住。
- OLAP 场景下，建议在 ETL 完成后再建位图索引，而不是边写边建
- 如果表有
UPDATE但频率不高（比如每日一次状态翻转），可以接受；但若有实时风控类UPDATE（每秒数百次），直接放弃位图索引 - Oracle 中可通过
DBA_INDEXES.BITMAP列确认是否为位图索引，别和FUNCTION-BASED索引混淆
分区表 + 位图索引，小心本地索引失效
在 Oracle 分区表上建位图索引，默认只能建全局位图索引（global bitmap index）。如果误建了本地位图索引（LOCAL），查询时优化器大概率不会用它——因为本地位图无法跨分区做位图合并，失去核心价值。
兼容性影响：PostgreSQL 不支持分区表上的位图索引（即使插件启用），建了也无效；Greenplum 倒是支持，但要求分区键必须包含在位图索引列中。
- Oracle 中建全局位图索引语法必须显式写
GLOBAL，不能省略：CREATE BITMAP INDEX idx_status ON orders(status) GLOBAL - 检查执行计划时，留意
BITMAP CONVERSION TO ROWIDS是否出现——没这个步骤，说明位图根本没参与执行 - 分区裁剪（partition pruning）和位图索引是两回事：即使只查一个分区，仍需完整位图运算，别以为“只扫一个分区就快”
位图索引不是低基数字段的银弹，它把存储结构、并发模型、优化器路径全绑在一起。很多人调完统计信息、建完索引发现没提速，问题往往出在查询写法没触发位图合并，或者压根不该在那个表上用它。
