【IT168专稿】第三届Oracle技术嘉年华再度来袭!作为国内顶尖级别的Oracle数据库技术盛会，现场邀请到Jonathan Lewis，Tim Gorman等Oracle数据库领域国际级专家，特别为中国的数据库爱好者带来他们多年的总结与经验分享。

▲中航信工程师 Oracle ACE ACOUG成员崔华

在本次大会上，Oracle ACE崔华给我们带来了《Oracle数据库优化器探秘》的精彩分享。在崔华看来，开发阶段就应该做到SQL的设计和调优，并知道在Oracle数据库中怎么用好SQL，怎么做好优化，自己也写了一本书《基于Oracle的SQL优化》。历经17个月的时间，熬夜到1-2点，终于完成了这本书。在崔华看来，尽管书不一定能够大卖，但是可以保证每一个看到这本书的人都能获得巨大的收益。

▲基于Oracle的SQL优化

我们谈及数据库的优化，而通常数据库80%的问题是由SQL引起的，因此只要解决SQL问题，就能够解决数据库80%的问题。崔华表示，开发者和DBA要想做好Oracle数据库优化，一定要了解优化器，而且要深入的了解。

优化器(Optimizer)是Oracle数据库中内置的一个核心子系统，你也可以把它理解成是Oracle数据库中的一个核心模块或者一个核心功能组件，优化器的目的是按照一定的判断原则来得到它认为目标SQL在当前情形下最高效的执行路径(Access Path)，也就是说优化器的目的就是为了得到目标SQL的执行计划。

依据选择执行计划时所用判断原则的不同，Oracle数据库里的优化器又分为RBO和CBO这两种类型。

▲Oracle数据库里SQL语句的执行过程

▲查找Shared Cursor的过程

Oracle数据库里SQL语句的执行过程-如果找到了Shared Cursor，优化器就可以滚粗了。

▲Oracle数据库里SQL语句的执行过程-如果找不到Shared Cursor，优化器这才粉墨登场

RBO的缺陷

1、选择执行计划时没有考虑目标SQL中所涉及到的各个对象的数据量、数据分布，只根据内置规则来决定执行计划——一招鲜、吃遍天。

2、执行计划一旦出了问题，我们很难对其做调整。

3、目标SQL的写法、甚至是目标SQL中所涉及到的各个对象在该SQL文本中出现的先后顺序和这些对象在数据字典缓存中的缓存顺序都可能会影响RBO对于该SQL执行计划的选择。

4、Oracle数据库中很多很好的特性、功能均不能在RBO下使用，因为它们均不被RBO所支持(例如哈希连接、函数索引等)。

CBO的局限

1、CBO会默认认为目标SQL语句where条件中出现的各个列之间是独立的，是没有关联关系的。

2、CBO会假设所有的目标SQL都是单独执行、并且是互不干扰的。

3、CBO对直方图统计信息有诸多限制：

-在Oracle 12c之前，Frequency类型的直方图所对应的Bucket的数量不能超过254。

-在Oracle数据库里，如果针对文本型的字段收集直方图统计信息，则Oracle只会将该文本型字段的文本值的头32个byte给取出来(实际上只取头15个byte)并将其转换成一个浮点数，然后将该浮点数作为上述文本型字段的直方图统计信息存储在数据字典里。

4、CBO在解析多表关联的目标SQL时，可能会漏选正确的执行计划。

CBO的优化方向

1、数据库的升级、统计信息的变更、CBO某些成本计算公式的先天不足等因素都会导致目标SQL执行计划的变更——这通常需要DBA来手工调整执行计划(手工调整执行计划太麻烦了，常常是按下了葫芦起了瓢)，我们希望Oracle数据库能自适应的自动调整不理想的执行计划，而且最好是一旦发现苗头不对，马上调整!

2、自适应查询优化。

3、突破现有限制、持续优化已有功能。

▲Oracle 12c的自适应查询优化

自适应执行计划之Adaptive Join Methods

初始表连接方法还是和原先一样：取决于现有的统计信息

最后采用的表连接方法直到目标SQL执行过程中才会确定

执行计划中多了一个组件：Statistic collector，最后采用的表连接方法依赖于目标SQL执行过程中statistics collector收集到的运行时统计信息

需要在一定程度上缓存目标SQL的执行结果，不能像原先的嵌套循环连接那样马上把执行结果返回给用户。

自适应统计信息之Dynamic statistics

以前叫Dynamic sampling，现在叫Dynamic statistics

Dynamic statistics会缓存在SGA中，它是基于目标SQL语句的where条件的，这意味着Dynamic statistics可以被可以被不同的SQL语句所共享

Dynamic statistics可以作为纠正统计信息缺失、不准的一种补充手段

优化器会根据目标SQL语句本身、已有统计信息和目标SQL的执行时间来决定是否采用Dynamic statistics。

自适应统计信息之Statistics feedback

以前叫Cardinality feedback，现在叫Statistics feedback

在目标SQL执行过程中，如果执行计划中的预估统计信息和该SQL实际执行时的运行时统计信息存在巨大差异，那么该SQL下次执行时会硬解析，并且此时生成执行计划的依据会是之前执行时已经收集好的运行时统计信息

Cardinality feedback只会收集单表和group by的运行时统计信息，Statistics feedback还会额外收集表连接的运行时统计信息

Cardinality feedback所对应的运行时统计信息存储在Shared Cursor里，不能持久化;而Statistics feedback所对应的运行时统计信息虽然也不能持久化，但此时可以用SQL Plan Directives(SPD)来优雅的缓解运行时统计信息不能持久化的问题，并且SPD可以持久化