大佬教程收集整理的这篇文章主要介绍了为什么Oracle会忽略“完美”指数？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
create table demo ( key number(10) NOT NULL,type VARCHAR2(3) not null,state varchar2(16) not null,... lots more columns ... )@H_618_8@而这个指数：
create index demo_x04 on demo(key,type,statE);@H_618_8@当我运行此查询时
SELEct * from demo where key = 1 and type = '003' and state = 'NEW'@H_618_8@EXPLAIN PLAN显示它进行全表扫描.所以我放弃了索引并再次创建它. EXPLAIN PLAN仍然表示全表扫描.怎么可能？
一些背景：这是历史数据,所以会发生的事情是我查找状态为CLEARED的行并插入一个状态为NEW的新行(加上我从旧行复制一些值).然后将旧行更新为USED.因此桌子总是在增长.我注意到的是索引的基数是0(尽管事实上我有数千个不同的值).重建后,基数增长但CBO不喜欢指数.
第二天早上,甲骨文突然喜欢这个索引(可能已经睡过了它)并且开始使用它但不是很长时间.过了一会儿,处理从50行/秒下降到3行/秒,我再次看到“FulL table SCAN”.到底是怎么回事？
就我而言,我需要处理大约一百万行.我批量提交变更. 50.在提交更新/重组索引之后是否应该运行一些命令？
我在使用Oracle 10g.
[编辑]我在这个表中有969’491个不同的键,3种类型和3种状态.
SELECT /*+ INDEX (demo demo_x04) */ * FROM demo WHERE key = 1 AND type = '003' AND state = 'NEW';@H_618_8@这听起来像是一夜之间发生的事情,表格得到了分析.然后,当您对表运行处理时,已更新足够的索引以使Oracle表的统计信息再次失效并且优化器停止使用索引.
添加提示,看看EXPLAIN PLAN是否为您提供了不同的计划,查询效果更好.
哦,Tony关于分析表格的答案是一般的良好做法,尽管10g数据库在这方面做自我维护非常好.如果您的进程正在进行大量更新,则索引可能会很快失效.如果在流程开始进入沟渠时运行分析会改善情况一段时间,那么您就会知道这就是问题所在.
要更新表的统计信息,请使用dmbs_stats.gather_table_stats程序包.
例如：
以上是大佬教程为你收集整理的为什么Oracle会忽略“完美”指数？全部内容，希望文章能够帮你解决为什么Oracle会忽略“完美”指数？所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。