如何解决不同SQL之间的性能冲突？

parrotao

原来richto是高手高手高高高高高高手

最初由 biti_rainy 发布
[B]怎么说曹操曹操就到啊
olive你就请教richto吧
他就是sql expert 的开发者
去LECCOTECH.COM ，他可能能帮你解决问题  ：） [/B]

machao

我以前碰到过一个6-7个表进行连接要几分钟才出结果,
当时用一个工具来看执行计划,都不能按照
理想的路径执行.
后来我先根据各表的索引表的大小逻辑关系,
人工找出哪二个表应该最先连接,是最优的,
,然后做一个function返回这两个表上的部分数据,
最后在select a.it,a.dd,b.dd,c.f,<function_name> from a,b,c ....
效果不错.
看看对你们有没参考作用.

lunar2000

对表作analyze estimate statistics，应该是使用基于开销的优化，看看你的参数文件中OTIMIZER_MODE的设置，如果=CHOOSE,就会激活基于开销的查询，如果有统计数字的话ORACLE会使用它；如果=RULE，则表示限制ORACLE使用基于规则的优化，那么你要仔细察看你的WHERE 子句中索引的列的使用当然还可以=FIRST_ROWS或者=ALL_ROWS，不管怎样，如果=CHOOSE,  FIRST_ROW ,  ALL_TOWS,那么，只要查询涉及的表中至少有一个表有了统计数字，ORACLE就会使用基于开销的查询，也就是说，ORACLE在根据不同的方法来估计开销（磁盘I/O，CPU资源的数量）来选择执行计划。另外，如果要使用基于开销的查询，那么，应该保持表及其索引的统计数字是最新的。

至于你的问题，首先看一下你选择的那种优化方法，如果是基于规则的查询，需要开发人员在些SQL时注意一些基本的SQL优化的方法，比如WHERE的构造等等，然后看看相应的列上是否建立了和时的索引等等。

lunar2000

最初由 olive 发布
[B]那么默认值是什么？
另外，经我试验，上述涉及到的表中，一定要某几个都analyze后，才有性能提高，比如我现在达到28分钟的执行时间，是analyze了其中四个表，少一个都不行。那oracle到底是怎么样选择优化方案的？ [/B]

刚刚不是说了么，
“不管怎样，如果=CHOOSE, FIRST_ROW , ALL_TOWS,那么，只要查询涉及的表中至少有一个表有了统计数字，ORACLE就会使用基于开销的查询”

补充一点，如果没有一个表有统计数字的话，oracle会使用基于规则的查询。

lunar2000

最初由 olive 发布
[B]那为什么我analyze少于四个表的时候，速度特别慢？和没有analyze的时候没有什么分别。
按照你的说法，只要有一个表有analyze，就是基于开销的啊。
按我的实验，必须要analyze四个表，速度才有突变。
谁能说说上面这个SELECT，应当怎样建立index。 [/B]

同意biti_rainy的说法

再看一遍回复中好么，
。。。。。“另外，如果要使用基于开销的查询，那么，应该保持表及其索引的统计数字是最新的。
”。。。。。。

lunar2000

最初由 parrotao 发布
[B]好运 [/B]

呵呵，是的，ANALYZE在使用时是该慎重的，要不回适得其反的，呵呵

dblife

这个问题我也碰到了
A表记录数目1000多万，原来建立了UNIQUE INDEX，SELECT * FROM A WHERE ....是走索引的
后面ANALYZE TABLE A COMPUTE STATISTICS FOR ALL INDEXES之后，就开始TABLE ACESS FULL了，ANALYZE TABLE DELETE STATISTICS之后，ANALYZE TABLE ESTAMITE也不行了。
加上/*+INDEX(A INDEX_NAME)*/也不行了，还是ACCESS FULL
我晕
看了PARROTAO给的连接 http://metalink.oracle.com/metal ... &p_id=84969.996
有点不知所措了，现在正在从新建立索引，巨慢无比。哎，有点不知所措了，看来以后分析也要小心再小心。

dblife

哦？还有这种问题，晕倒
oracle这个破东西，呵呵
我一直以为analyze table emp compute statistics for all indexes就一切ok了
至于estimate不过是因为表太大，分析时间过长，才采用呢

dblife

而且还有一个问题，就是estimate分析好像是有时候导致走索引有的时候也无效的
昨天晚上我清楚记得estimate了一次，结果还是table access full,今天早上又estimate一次
又开始用索引了，总之，一团糟

dblife

嗯，我觉得先analyze table compute or estimate
再analyze table compute or estimate for all indexes 就ok了