位图索引对Star Join至关重要，因其使Oracle能用BITMAP AND压缩多维度过滤结果为位图，直接定位事实表满足条件的行，避免全表扫描。
星型连接（Star Join）在Oracle中不会自动变快，必须配合位图索引 + 星型转换参数开启，否则就是普通嵌套循环或哈希连接，事实表照样全扫。
为什么位图索引对Star Join至关重要
星型查询的瓶颈从来不在维度表（小、过滤强），而在事实表（大、无筛选）。位图索引的作用不是“加速JOIN”，而是让Oracle能用BITMAP AND把多个维度表的过滤结果压缩成一个位图，再直接定位事实表中满足所有条件的行——跳过全表扫描。
常见错误现象：EXPLAIN PLAN里看到TABLE ACCESS FULL on SALES，哪怕WHERE里写了CUSTOMERS.CUST_STATE_PROVINCE = 'CA'也无效。
- 位图索引只对低基数列（如状态、渠道类型、季度描述）有效；高基数列（如订单ID、时间戳）建位图索引反而拖慢DML
- 必须建在事实表的外键列上，例如
SALES.TIME_ID、SALES.CUST_ID，而不是维度表的主键列 - 分区事实表建议加
LOCAL关键字，避免全局索引维护开销
STAR_TRANSFORMATION_ENABLED参数怎么设才真正生效
设成TRUE只是“允许”优化器尝试星型转换，不等于“一定用”。是否启用取决于CBO估算：转换后成本是否低于原计划。如果位图索引缺失、统计信息陈旧、或某个维度表过滤率太差（比如WHERE CHANNEL_DESC LIKE '%'），优化器会直接放弃。
实操建议：
- 确认当前值：
SHOW PARAMETER star_transformation_enabled，默认是FALSE - 生产环境慎用
ALTER SYSTEM，优先用ALTER SESSION测试：ALTER SESSION SET star_transformation_enabled = TRUE - 遇到大维度表触发临时表膨胀（报错
ORA-12801或大量TEMP段争用），改用TEMP_DISABLE：ALTER SESSION SET star_transformation_enabled = TEMP_DISABLE - 隐含参数
_temp_tran_block_threshold控制“多大算大维度表”，默认100个数据块，可通过SELECT blocks FROM user_tables WHERE table_name = 'CUSTOMERS'预估
位图联结索引（Bitmap Join Index）比普通位图索引更省事
当常用过滤条件在维度表非主键列（比如CUSTOMERS.CUST_STATE_PROVINCE），每次都要先JOIN再过滤，普通位图索引帮不上忙。这时建位图联结索引，能把维度表字段“预关联”进事实表索引里。
示例语句：
CREATE BITMAP INDEX sales_cust_state_bjix ON sales(customers.cust_state_province) FROM sales, customers WHERE sales.cust_id = customers.cust_id LOCAL;
注意点：
- 索引定义里必须显式写出
FROM和WHERE关联条件，不能只写字段名 - 依赖的外键关系必须存在（
SALES.CUST_ID→CUSTOMERS.CUST_ID），否则建索引报ORA-25954 - 该索引会锁定维度表的主键列，建索引期间
CUSTOMERS表上的DML可能被阻塞
统计信息不准会导致星型转换完全失效
Oracle靠统计信息判断维度表的过滤选择率。如果CUSTOMERS表的CUST_STATE_PROVINCE列没有直方图，优化器可能误判“= 'CA'”只过滤掉1%数据，从而拒绝星型转换。
关键操作：
- 收集事实表外键列的直方图：
DBMS_STATS.GATHER_TABLE_STATS时指定method_opt => 'FOR COLUMNS SIZE AUTO CUST_ID, TIME_ID' - 维度表本身也要收集完整统计：
DBMS_STATS.GATHER_TABLE_STATS('SH', 'CUSTOMERS') - 避免用
ANALYZE TABLE，它不收集直方图且已弃用
最易被忽略的一点：位图索引本身不存储NULL值，如果事实表外键列存在大量NULL（比如促销ID为空），而查询又没排除NULL，BITMAP AND结果可能为空，导致星型转换退化为全表扫描。建索引前先检查：SELECT COUNT(*) FROM sales WHERE cust_id IS NULL。
