Oracle位图索引异常：原表未用索引，复制表正常生效

这种情况我之前碰过好几次，真的挺让人费解的——明明索引创建语句完全一样，原表就是死活不肯用，副本却秒生效。别着急，咱们从几个最可能的方向入手排查：

1. 原表的统计信息大概率“过期”或不准确 #

你建索引时加了COMPUTE STATISTICS，但原表可能之前的统计信息已经失真，导致优化器对col1的基数判断出错。位图索引对列的基数特别敏感：如果col1的唯一值太多（基数高），优化器会觉得位图索引的成本比全表扫描还高；而副本表是新生成的，统计信息更精准，能正确评估索引价值。

试试手动刷新原表的全量统计信息（记得替换成你的实际用户名）：

EXEC DBMS_STATS.GATHER_TABLE_STATS('你的用户名', 'TABLE1', CASCADE => TRUE);

CASCADE => TRUE会同时更新关联索引的统计信息，确保优化器拿到的是最新数据。

2. 原表的列分布直方图有偏差 #

如果col1的数据分布极不均匀（比如90%都是同一个值，剩下10%是其他值），原表的直方图可能没正确捕捉到这种规律，导致优化器选错执行计划。而副本表是新插入的数据，直方图是重新生成的，能准确反映数据分布。

先查看col1的直方图状态：

SELECT column_name, histogram 
FROM user_tab_columns 
WHERE table_name = 'TABLE1' AND column_name = 'COL1';

如果直方图不是FREQUENCY（适合重复值多的列）或HEIGHT BALANCED（适合分布均匀的列），可以手动生成适配的直方图：

EXEC DBMS_STATS.GATHER_TABLE_STATS(
    ownname => '你的用户名',
    tabname => 'TABLE1',
    method_opt => 'FOR COLUMNS COL1 SIZE AUTO'
);

3. 原表存在大量存储碎片 #

原表长期使用后，可能积累了大量存储碎片，导致全表扫描的IO成本被优化器低估，反而觉得比走索引更划算。而副本表是新建的，存储结构规整，IO成本计算更准确。

可以尝试重组原表并重建索引：

-- 移动表来整理碎片
ALTER TABLE TABLE1 MOVE;
-- 移动表后索引会失效，必须重建
ALTER INDEX IDX_1 REBUILD;

4. 检查是否有SQL基线/Profile强制全表扫描 #

有时候，之前的查询可能被绑定了SQL Profile或者SQL Plan Baseline，强制优化器使用全表扫描的执行计划，哪怕你新建了索引也没用。

检查是否存在针对原表查询的基线或Profile：

-- 检查SQL Profile
SELECT name, type 
FROM sql_profiles 
WHERE sql_text LIKE '%TABLE1%';

-- 检查SQL Plan Baseline
SELECT name 
FROM dba_sql_plan_baselines 
WHERE sql_text LIKE '%TABLE1%';

如果发现有相关条目，可以考虑删除或者更新，让优化器重新选择执行计划。

5. 用优化器提示验证索引本身是否可用 #

你提到尝试过优化器提示，那可以直接在查询里强制指定索引，看看索引本身是否能正常工作：

SELECT /*+ INDEX(TABLE1 IDX_1) */ * 
FROM TABLE1 
WHERE COL1 = '你要查询的取值';

• 如果加了提示后能正常走索引，说明索引本身没问题，问题出在优化器的成本计算上，回到前面的统计信息、直方图排查即可。
• 如果加了提示还是不走索引，那检查索引状态是否正常：

  SELECT index_name, status 
  FROM user_indexes 
  WHERE index_name = 'IDX_1';
  

  确保状态是VALID，如果不是，再重建一次索引试试。

内容的提问来源于stack exchange，提问作者akaipbay