今天在调一些固定的SQL，调整一下写法，加点注释，改几个别名什么的，本身没什么事情。 结果在其中某一个SQL的时候，忽然卡住了。一共是三个左连接一个EXISTS，每张表都不超过一百万行。按道理说，这种SQL就算慢，也不会超过一分钟，就得出结果。结果执行的
今天在调一些固定的SQL，调整一下写法，加点注释，改几个别名什么的，本身没什么事情。
结果在其中某一个SQL的时候，忽然卡住了。一共是三个左连接一个EXISTS，每张表都不超过一百万行。按道理说，这种SQL就算慢，也不会超过一分钟，就得出结果。结果执行的效果让我很困惑。头一次执行的时候很快，非常快，两秒出结果。再执行一次，就要很久了，反正我是没等到过结果。最长一次等了半小时，我中午饭都吃完了思密达。。。
看计划，没问题，一点问题都没有。看数据库的负载，也没什么问题。可以说库是很闲的。那这是为啥？能执行，能有速度快的，说明Oracle能找到基本正确的计划。但是为什么第二次会慢呢？一下子就想到了一个新特性，11g里对执行计划的新改进。
_OPTIMIZER_USE_FEEDBACK
简单可以理解为这是Oracle对CBO的一种持续改进。本身PLAN就是基于各种数据对实际执行时间的一种推测，COST也是基于一些算法得到的结果，不是一个确切的值。当Oracle执行过这个语句以后，可以在实际环境中得到一些采样结果，这些结果是实际跑出来的，不是推测或者算出来的。这些值比计算得到的COST和ROWS要来的靠谱的多，于是11g就打算用这些值来做动态推测，基于一个可信的执行计划的详细明细来得到更加贴切实际的计划改进。
但是俗话说的好，Oracle不到R2不要用，咳咳。。。
我的SQL就是被这个参数给搞了一下，Oracle依据首次执行的结果优化了，然后我郁闷了。。。
说说验证和解决办法吧。验证的话可以加HINT，OPT_PARAM(’_OPTIMIZER_USE_FEEDBACK‘，‘FALSE’)。如果加过以后，执行效果不再乱飘了，那么就去把这个隐含参数改成false吧。
提示一下，改隐含参数要加引号，写成“a“=b的样子，具体怎么改就不说了，能看到这里的人，改个参数还是会的，是吧。可以改session和system，都不用重启。
原文地址：11g新特性之忽快忽慢的执行速度, 感谢原作者分享。
