当出现应用较慢的情况时，我们可以首先用oem抓出sql，然后再进行详细的分析。

select nvl(to_char(status), 'null') status, 
nvl(to_char(subscribeid), 'null')
subscribeid
from abc
where status > 0
and replace(bbid, '''', '') = '9999-0009-11111'。

具体分析：

1.检查表是否分析。用oem查看schema下的table，右栏可以显示last analyzed的日期。结果显示表已分析过。

2.用set auotrace traceonly; set timing on 看执行计划以及执行时间，发现是full scan，运行时间大概是18秒。

3.查看索引的选择性，所谓选择性高，是指列中某个值的个数在正个列中所占比例低。如1个表中有1000行，某列中值为1的个数为10个，则如果此列建立索引的话，是能提高查询速度的。而如果值为1的个数在900个，oracle可能就会选择full scan。这种情况叫可选择性低。

sql>select count(*) from abc where status >0 ;

发现行数就是表的行数。则即使建立索引，cbo也会选择full scan。

4.再看replace(bbid, '''', '') = '9999-0009-11111'，虽然bbid建立了索引，但由于加了hanshu raplace的缘故，索引不会生效。

以上几点就是为什么执行计划选择full的具体原因。

解决的方法；

加一个函数索引：

sql>create index inx_func_abc on abc(replace(bbid, '''', ''));

在加完索引后，我们需要进行分析。

sql>begin
sys.dbms_stats.gather_index_stats (
ownname => 'abc'
,indname => 'idx_func_abc'
,estimate_percent => 10
,degree => sys.dbms_stats.default_degree
,no_invalidate => false);
end;
/

我们可以发现，在加了函数索引后，性能得到了显著的提高。