CBO prefer index skip scan
在10.2.0的OFE环境中,当表上的统计信息都是0的时候,Oracle倾向于使用index skip scan,而不是index unique or range scan。
相关 Bug 5714944,在11gR2中测试已经被解决。
CBO may choose an INDEX SKIP SCAN instead of an INDEX UNIQUE SCAN
when statistics indicate that the table/index is empty. This
can lead to a suboptimal plan if there are really some rows
in the table.This fix adjusts the cost of an INDEX SKIP SCAN to be at least 1.0 .
Workaround : Hint the preferred access path.
Note:
This fix can be enabled / disable using the “_fix_control” parameter.
当OFE=10*且_optimizer_skip_scan_enabled=TRUE的时候就会触发。10g OFE还有好多bug,自我感觉还是8174的OFE聪明。



















OFE 是什么缩写,啥意思?
optimizer_features_enable. 我们大部分数据库还用8.1.7那。
不着急,慢慢摇. ^_^
我在真实环境里遇到的oracle偏向于使用index skip scan,我发现oracle对skip scan计算cost的算法肯定有问题,一定是cost 计算的偏小了,我的情况是统计信息准确,语句类似
select * from table where a= and b>=
一个索引是(a,b) 一个是(c,b,a),一个是(b,a)
oracle竟然偏向于选择(c,b,a)的索引做skip scan,我对比了clustering_factor这
2个索引是一样的
但是选择(c,b,a)的cost比(a,b)的小很多
但是实际执行的时候逻辑读大很多
最近又被这个参数搞了,彻底下定决心disable index_skip_scan globally.
我前段时间也被这个撂倒了,,我们这边已经在9i中彻底关闭index skip scan了..
alter system set “_optimizer_skip_scan_enabled” = false scope=spfile;
bounce db.
曾经有一次在客户现场把这个给禁用了,差点把自己搞死了,一禁用发现gc buffer busy突然全崩出来,发现有些sql还是得skip scan,哈哈,没有选择性高的单列索引,所以我宁愿加hint禁用语句的skip scan,也不改系统参数,未知性太多