同一语句，10g和11g的执行计划差距很大，求解？？

[请叫我-雷人]

直接上图

表数据和索引什么的一致，为什么呢？求大家指教

[quanhj]

数据量、索引信息信息的收集这些也要考虑进去啥

[ckc]

引用 4 楼 qq304213346 的回复:

[quote=引用 3 楼 ckc 的回复:] oracle运行具有严重的不确定性 别说不同的版本了，相同的版本在同一台机器上都会有不同的执行计划 这个很可能跟oracle自作聪明的优化有关系 我们生产上就经常遇到这样的事情，一个很正常的业务突然就速度很慢， 重新执行一次也许就好了，删除掉索引信息什么的也会有帮助 一般来说最终解决方案多半是在sql中强制指定索引

我把索引删了，确实有效果，更慢了。。。。[/quote] 汗，我的意思是删除oracle的统计信息， analyze table 表名 delete statistics 曾经有个应用需要每次在一个操作之前执行这个命令，不然速度就很慢 或者在查询中强制指定索引 select /*+ index(索引名) */ ...........

[请叫我-雷人]

引用 9 楼 ckc 的回复:

[quote=引用 4 楼 qq304213346 的回复:] [quote=引用 3 楼 ckc 的回复:] oracle运行具有严重的不确定性 别说不同的版本了，相同的版本在同一台机器上都会有不同的执行计划 这个很可能跟oracle自作聪明的优化有关系 我们生产上就经常遇到这样的事情，一个很正常的业务突然就速度很慢， 重新执行一次也许就好了，删除掉索引信息什么的也会有帮助 一般来说最终解决方案多半是在sql中强制指定索引

我把索引删了，确实有效果，更慢了。。。。[/quote] 汗，我的意思是删除oracle的统计信息， analyze table 表名 delete statistics 曾经有个应用需要每次在一个操作之前执行这个命令，不然速度就很慢 或者在查询中强制指定索引 select /*+ index(索引名) */ ........... [/quote] 我删掉了分析数据，然后optimizer_mode改成了choose。 速度提升了一个数量级

[请叫我-雷人]

加强制索引没什么效果

[请叫我-雷人]

引用 8 楼 lu010610 的回复:

你看看执行计划一个Merge Sort Join，一个是Hash Join？为什么呢 朝这方面看看？

恩。试了半天也没试出什么结果，所以感觉影响不大。学的太浅

[请叫我-雷人]

引用 1 楼 quanhj 的回复:

数据量、索引信息信息的收集这些也要考虑进去啥

数据量和索引保持一致。

[ckc]

oracle运行具有严重的不确定性 别说不同的版本了，相同的版本在同一台机器上都会有不同的执行计划 这个很可能跟oracle自作聪明的优化有关系 我们生产上就经常遇到这样的事情，一个很正常的业务突然就速度很慢， 重新执行一次也许就好了，删除掉索引信息什么的也会有帮助 一般来说最终解决方案多半是在sql中强制指定索引

[-騎豬看海-]

结贴了吗?

引用 10 楼 qq304213346 的回复:

[quote=引用 9 楼 ckc 的回复:] [quote=引用 4 楼 qq304213346 的回复:] [quote=引用 3 楼 ckc 的回复:] oracle运行具有严重的不确定性 别说不同的版本了，相同的版本在同一台机器上都会有不同的执行计划 这个很可能跟oracle自作聪明的优化有关系 我们生产上就经常遇到这样的事情，一个很正常的业务突然就速度很慢， 重新执行一次也许就好了，删除掉索引信息什么的也会有帮助 一般来说最终解决方案多半是在sql中强制指定索引

我把索引删了，确实有效果，更慢了。。。。[/quote] 汗，我的意思是删除oracle的统计信息， analyze table 表名 delete statistics 曾经有个应用需要每次在一个操作之前执行这个命令，不然速度就很慢 或者在查询中强制指定索引 select /*+ index(索引名) */ ........... [/quote] 我删掉了分析数据，然后optimizer_mode改成了choose。 速度提升了一个数量级[/quote]

[请叫我-雷人]

引用 3 楼 ckc 的回复:

oracle运行具有严重的不确定性 别说不同的版本了，相同的版本在同一台机器上都会有不同的执行计划 这个很可能跟oracle自作聪明的优化有关系 我们生产上就经常遇到这样的事情，一个很正常的业务突然就速度很慢， 重新执行一次也许就好了，删除掉索引信息什么的也会有帮助 一般来说最终解决方案多半是在sql中强制指定索引

我把索引删了，确实有效果，更慢了。。。。

[请叫我-雷人]

略吊！

[ccjk311]

表和索引的统计信息也一致吗

[ccjk311]

如果statices信息也一样，那表和索引的存储（块大小、PCT free之类的）是否一样？

[_拙计]

你看看执行计划一个Merge Sort Join，一个是Hash Join？为什么呢 朝这方面看看？

[请叫我-雷人]

引用 13 楼 u010682529 的回复:

结贴了吗? [quote=引用 10 楼 qq304213346 的回复:] [quote=引用 9 楼 ckc 的回复:] [quote=引用 4 楼 qq304213346 的回复:] [quote=引用 3 楼 ckc 的回复:] oracle运行具有严重的不确定性 别说不同的版本了，相同的版本在同一台机器上都会有不同的执行计划 这个很可能跟oracle自作聪明的优化有关系 我们生产上就经常遇到这样的事情，一个很正常的业务突然就速度很慢， 重新执行一次也许就好了，删除掉索引信息什么的也会有帮助 一般来说最终解决方案多半是在sql中强制指定索引

我把索引删了，确实有效果，更慢了。。。。[/quote] 汗，我的意思是删除oracle的统计信息， analyze table 表名 delete statistics 曾经有个应用需要每次在一个操作之前执行这个命令，不然速度就很慢 或者在查询中强制指定索引 select /*+ index(索引名) */ ........... [/quote] 我删掉了分析数据，然后optimizer_mode改成了choose。 速度提升了一个数量级[/quote][/quote] 没呢？有何指教。

[请叫我-雷人]

今个来发现又卡死了，执行计划和最上面那张图差不多。然后清了analyze的分析信息，在执行如图：


但是执行还是慢。按说1分钟内也应该出来啊，但貌似还是卡死。无语。。。