为什么 Oracle 会忽略“完美”索引？

我有这张表：

create table demo (
    key number(10) not null,
    type varchar2(3) not null,
    state varchar2(16) not null,
    ... lots more columns ...
)

和这个索引：

create index demo_x04 on demo(key, type, state);

当我运行这个查询时

select * from demo where key = 1 and type = '003' and state = 'NEW'

EXPLAIN PLAN显示它进行了全表扫描。所以我删除了索引并重新创建了它。EXPLAIN PLAN还是说全表扫描。怎么可能？

一些背景：这是历史数据，所以发生的情况是我查找带有状态的行CLEARED并插入一个带有状态的新行NEW（另外，我从旧行复制了一些值）。然后旧行更新为USED。所以桌子总是在增长。我注意到索引的基数是 0（尽管我有数千个不同的值）。重新创建后，基数增加了，但 CBO 不再喜欢该索引。

第二天早上，Oracle 突然喜欢上了这个索引（可能是睡过头了）并开始使用它，但时间不长。一段时间后，处理速度从 50 行/秒下降到 3 行/秒，我再次看到“全表扫描”。到底是怎么回事？

就我而言，我需要处理大约一百万行。我批量提交更改。 50. 在提交更新/重组索引或类似的命令后，我是否应该运行一些命令？

我使用的是 Oracle 10g。

[编辑] 我在这个表中有 969'491 个不同的键，3 种类型和 3 种状态。

如果指定索引提示会发生什么？尝试这个：

SELECT /*+ INDEX (demo demo_x04) */ * 
  FROM demo 
 WHERE key = 1 
   AND type = '003' 
   AND state = 'NEW';

听起来好像一夜之间发生的事情就是对表格进行了分析。然后，当您对表运行处理时，足够的索引被更新，导致 Oracle 表的统计信息再次过时，优化器停止使用索引。

添加提示并查看 EXPLAIN PLAN 是否为您提供不同的计划并且查询性能更好。

哦，托尼关于分析表的回答是一个普遍的好习惯，尽管 10g 的数据库在这方面进行自我维护非常好。如果您的进程正在进行大量更新，索引可能很快就会过时。如果当你的进程开始陷入困境时运行分析可以暂时改善情况，那么你就会知道这就是问题所在。

要更新表的统计信息，请使用dbms_stats.gather_table_stats http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461包裹。

例如：

exec dbms_stats.gather_table_stats('所有者','DEMO');