star join 加速需同时满足三条件：事实表外键列有位图索引、star_transformation_enabled=true、维度表连接列有主键或唯一约束；缺一不可。
Star Join 不会自动变快，必须同时满足三个硬性条件：事实表外键列上有位图索引、STAR_TRANSFORMATION_ENABLED=TRUE、维度表连接列有主键或唯一约束；缺一不可。
为什么加了位图索引，EXPLAIN PLAN 还是 TABLE ACCESS FULL？
常见错误现象是明明在 SALES.CUST_ID 上建了位图索引，WHERE 里也写了 CUSTOMERS.CUST_STATE_PROVINCE = 'CA'，但执行计划里仍看到对 SALES 表的全表扫描。
- 根本原因不是“没建索引”，而是优化器压根没走星型转换路径——它连尝试都没尝试
- 检查
SHOW PARAMETER star_transformation_enabled，默认值是FALSE，不改就等于没开开关 - 即使设成
TRUE，优化器仍可能放弃：比如某个维度表过滤率太差（WHERE CHANNEL_DESC LIKE '%'）、统计信息陈旧、或某个维度表太大触发临时表膨胀后被降级 - 确认是否真用了星型转换：执行计划中要出现
STAR TRANSFORMATION或BITMAP MERGE操作符，而不是单纯看到BITMAP INDEX SINGLE VALUE
位图索引必须建在事实表外键列上，不是维度表主键列
这是最容易搞反的操作。位图索引的作用对象是事实表的筛选动作，不是维度表的查找效率。
- 正确位置：
CREATE BITMAP INDEX sales_cust_bix ON SALES(CUST_ID) LOCAL;—— 建在SALES表的外键列上 - 错误做法：
CREATE BITMAP INDEX cust_pk_bix ON CUSTOMERS(CUST_ID);—— 这只是普通位图索引，对星型连接无用 - 如果常用过滤字段在维度表非主键列（如
CUSTOMERS.CUST_STATE_PROVINCE），得用位图连接索引：CREATE BITMAP INDEX sales_state_bix ON SALES(CUSTOMERS.CUST_STATE_PROVINCE) FROM SALES, CUSTOMERS WHERE SALES.CUST_ID = CUSTOMERS.CUST_ID; - 注意：该语句会失败如果
CUSTOMERS.CUST_ID没有主键或唯一约束（报错ORA-25954）
STAR_TRANSFORMATION_ENABLED 设成 TRUE 就万事大吉？
不是。这个参数只是“允许”优化器考虑星型转换，不等于“强制启用”。实际是否生效，完全取决于成本估算结果。
- 生产环境别直接
ALTER SYSTEM，先用ALTER SESSION SET star_transformation_enabled = TRUE;测试单条 SQL - 遇到 ORA-12801 或大量 TEMP 段争用，说明某个维度表太大（比如
BLOCKS > 100），可临时切到TEMP_DISABLE模式：ALTER SESSION SET star_transformation_enabled = TEMP_DISABLE; - 位图索引只对低基数列有效：
CUST_STATE_PROVINCE（几十个取值）合适，CUST_NAME（百万级唯一值）建了反而拖慢 DML - 多个位图索引要一起用才有意义：单个
SALES.CUST_ID索引效果有限，但配合SALES.TIME_ID和SALES.CHANNEL_ID，优化器才能做BITMAP AND合并，跳过全表扫描
位图连接索引的语法和限制比普通位图索引更严
它不是语法糖，而是一套强约束的预关联机制。写错一个字符，Oracle 就拒绝创建，或者建出来也不起作用。
- FROM 子句只能有两个表，且第二个必须是维度表：
FROM SALES, CUSTOMERS✅；FROM SALES, CUSTOMERS, TIMES❌ - WHERE 条件只能有一个等值连接，且两边列必须分别属于两个表：
WHERE SALES.CUST_ID = CUSTOMERS.CUST_ID✅；WHERE UPPER(CUSTOMERS.CUST_STATE_PROVINCE) = 'CA'❌（函数导致失效） - 维度表连接列必须是主键或唯一约束；如果是复合主键（如
(PROD_CATEGORY, PROD_SUBCATEGORY)），WHERE 中必须同时写出两个列 - 索引列必须来自维度表，且只能是标量字段，不能是表达式、函数或伪列
真正难的不是建索引，而是让优化器相信星型转换比嵌套循环或哈希连接更便宜——这依赖于准确的统计信息、合理的基数预估、以及没有隐式类型转换或函数包装破坏谓词可推导性。哪怕所有配置都对，只要 ANALYZE 没跑，它就可能退化。
