位图连接索引只能建在事实表上，索引列须来自维度表且维度表连接列需有主键或唯一约束；仅支持单层等值内连接，FROM限两表、WHERE限一个等值条件；适用于低基数字段，高基数或LIKE/范围查询不适用；DML会引发锁争用，仅适合ETL后只读场景。
位图连接索引只能建在事实表上，且索引列必须来自维度表
位图连接索引不是给维度表建的，而是以事实表为“宿主”、把维度表的字段“搬进来”做索引列。比如你想按 JOBS.JOB_TITLE 快速过滤员工，索引必须建在 EMPLOYEES 表上，语法是 CREATE BITMAP INDEX ... ON EMPLOYEES(JOBS.JOB_TITLE)。反过来说，CREATE BITMAP INDEX ... ON JOBS(EMPLOYEES.EMP_NAME) 是非法的——Oracle 会直接报错 ORA-25954（缺失主键约束）或 ORA-25960（维度列表达式不合法）。
常见错误现象：
- 执行
CREATE BITMAP INDEX时提示ORA-25954: missing primary key or unique constraint on dimension table：说明WHERE子句中维度表的连接列（如JOBS.JOB_ID）没有主键或唯一约束； - 误把索引建在维度表上，语句看似能执行，但实际创建的是普通位图索引，不会触发连接逻辑，查询计划里也看不到索引被用上。
FROM + WHERE 子句写法必须严格匹配星型模式连接路径
位图连接索引的语法本质是“声明一个轻量级物化连接”，所以 FROM 和 WHERE 不是可选修饰，而是强制结构。它只支持单层等值内连接，且不能出现自连接、外连接或连接链（A→B→C）。例如：
✅ 正确：CREATE BITMAP INDEX emp_job_title_idx ON EMPLOYEES(JOBS.JOB_TITLE) FROM EMPLOYEES, JOBS WHERE EMPLOYEES.JOB_ID = JOBS.JOB_ID;
❌ 错误：CREATE BITMAP INDEX ... ON EMPLOYEES(DEPARTMENTS.DEPARTMENT_NAME) FROM EMPLOYEES, DEPARTMENTS, LOCATIONS WHERE EMPLOYEES.LOCATION_ID = LOCATIONS.LOCATION_ID AND LOCATIONS.LOCATION_ID = DEPARTMENTS.LOCATION_ID; —— 这属于连接链，Oracle 不支持。
关键限制点：
-
FROM中最多两个表，且第二个必须是维度表； -
WHERE中只能有一个等值连接条件，且两边列必须分别属于两个表； - 如果维度表有复合主键（如
(PROD_CATEGORY, PROD_SUBCATEGORY)），则WHERE条件中必须同时包含这两个列，缺一不可。
低基数字段才值得建位图连接索引，高 Cardinality 列反而拖慢性能
位图索引天然适合值少、重复多的字段，比如 STATUS（'Y'/'N'）、GENDER（'M'/'F'/'O'）、CHANNEL_DESC（'Direct_sales'/'Online'/'Retail'）。一旦字段取值超过几百个（比如客户姓名、产品描述），位图索引体积会急剧膨胀，压缩失效，扫描开销反超 B*Tree。
判断是否适用，先查基数：
SELECT COUNT(DISTINCT JOB_TITLE), COUNT(*) FROM JOBS;
如果比值 > 0.01（即唯一值占比超 1%），基本不建议建位图连接索引。更稳妥的做法是结合查询模式看：如果你的 WHERE 条件经常是 JOB_TITLE IN ('Accountant', 'Analyst', 'Clerk') 这类小集合筛选，位图的 AND/OR 位运算才有优势；如果是 JOB_TITLE LIKE '%manager%' 或范围查询，则完全用不上。
容易踩的坑：
- 在
EMPLOYEES.FIRST_NAME上建位图连接索引——名字重复率极低，索引块数可能接近行数，失去位图压缩意义； - 没更新统计信息就建索引，优化器不知道新索引的存在，执行计划仍走全表扫描；建完务必跑
DBMS_STATS.GATHER_TABLE_STATS。
事实表 DML 会阻塞索引维护，OLTP 场景下基本不可用
位图连接索引不是“自动同步”的。当事实表发生 INSERT/UPDATE/DELETE 时，Oracle 必须实时重算对应维度值的位图段——这个过程会锁住整条位图记录（不是单行），并发修改极易引发 enq: TX - row lock contention。这意味着它只适用于 ETL 批量加载后几乎只读的事实表。
真实运维中的硬约束：
- 禁止在业务高峰期对已建位图连接索引的事实表执行 DML；
- 如果必须更新，建议先
ALTER INDEX ... UNUSABLE，DML 完成后再ALTER INDEX ... REBUILD； - 分区事实表可针对性地禁用/重建某分区索引，避免全表锁，但需确保分区键与连接条件无关（否则索引失效）。
最常被忽略的一点：即使你只更新事实表中某几行，只要这些行关联的维度值（如 JOB_TITLE）在索引中存在，整个该值对应的位图段都会被加锁。这不是细粒度控制，而是设计使然。
