上海网站建设百度推广公司深圳百度推广联系方式
优化器:分为RBO 和CBO 两种类型,RBO(Rule-Based Optimizer)基于规则的优化器,CBO(Cost-Based Optimizer)基于成本的优化器。目的是为了得到目标SQL的执行计划。
SQL语句的执行过程：
RBO：
Oracle会在代码里事先为各种类型的执行路径定一个等级，一共15个等级，从等级1到等级15，oracle认为等级1（通过rowid：single row by rowid）的执行路径是效率最高的，等级15(全表扫描: full table scan)是执行效率最差的。对于等级相同的执行计划，oracle根据目标对象的在数据字典中缓存的顺序判断选择哪一种执行计划。RBO是一种适合于OLTP类型SQL语句的优化器。相对于CBO而言，RBO有着先天的缺陷，一旦SQL语句的执行计划出现问题，将很难调整。那么RBO执行计划出现问题，怎么调整目标SQL的执行计划呢？一般有如下方法：等价改写目标SQL，比如在where条件对number和date类型的列添加0（deptno+0>100），varchar2或char类型的列可以添加一个“空字符”，例如“||”。对于多表连接的SQL，前提目标SQL有两条或以上的执行路径的等级值相同，可以改变from表的连接顺序（RBO会按照从右往左的顺序决定谁是驱动表，谁是被驱动表。）(右边的是驱动表，左边的是被驱动表)来达到改变目标SQL执行计划的目的。我们也可以改变相关对象在数据字典中缓存的顺序（创建顺序），来改变执行计划（后创建的先执行）。RBO最大的缺点是以oracle内置代码的规则作为判断标准，而并没有考虑到实际目标表的数据量以及数据分布情况。
以下情形,修改优化器模式或使用rule Hint ,不会使用RBO(强制使用CBO)：
- 目标ＳＱＬ中涉及的对象有IOT（Index Organized Table）
- 目标ＳＱＬ中涉及的对象有分区表
- 使用了并行查询或者并行DML
- 使用了星型连接
- 使用了哈希连接
- 使用了索引快速全扫描
- 使用了函数索引
CBO：
CBO选择执行计划时，以目标SQL成本为判断原则，CBO会选择一条执行成本最小的执行计划作为SQL的执行计划，各条执行路径的成本通过目标SQL语句所涉及的表、索引、列等的统计信息算出。这里的成本是oracle通过相关对象的统计信息计算出来的一个值，它实际上代表目标SQL对应执行步骤所消耗的IO、CPU、网络资源（针对于dblink下的分布式数据库系统而言）的消耗量，oracle会把网络资源的消耗量计算在IO成本内，实际上你看到的成本为IO、CPU资源，另外需要注意的是，oracle在未引入系统统计信息之前，CBO所计算的成本值实际全是基于IO计算的。
1、集的势（cardinality）
Cardinality是CBO特有的概念，指集合所包含的记录数，即结果集行数。Cardinality实际上表示对目标SQL某个具体执行步骤的执行结果所包含的记录数的估算，当然，如果针对整个目标SQL，那么此时的cardinality就表示对该SQL最终执行结果所包含的记录数的估算。Cardinality和成本值得估算息息相关，因为oracle得到的制定结果集所需要消耗的IO资源可以近似的看成随着结果集所包含的记录数递增而递增。所以，SQL编写的一个原则就是“尽早的过滤更多的数据”。（Cardinality越大，成本越大）
2、可选择率（Selectivity）
Selectivity也是CBO特有的概念，它是指“施加指定谓语条件后返回的结果集的记录数占未施加任何谓语条件的原始结果集的记录数的比率”，取值范围为0~1，其值越小，代表可选择性越好。Selectivity也可成本值得估算息息相关，可选择率越大，意味着所返回的结果集的cardinality越大，所以估算的成本就越大。实际上CBO就是利用selectivity来计算对应结果集的cardinality的，即：
Computed cardinality=original*selectivity
Cardinility和selectivity的值会直接影响CBO对于相关执行步骤成本的估算，进而影响CBO对于目标SQL的执行计划的选择。
3、可传递性
可传递性也是CBO的特有属性，它是查询转换中所做的第一件事情，其含义是CBO会对目标SQL做等价改写，进而提供更多的执行路径给目标CBO，增加得到最佳执行计划的可能性。RBO不会对目标SQL做等价改写。Oracle里可传递性分为以下3种情况：
1）简单谓语传递
比如原目标SQL中的谓语条件是“t1.c1=t2.c1 and t1.c1=10”,则CBO可能会给谓语条件额外加上“t2.c1=10”。
2）连接谓语传递
比如原目标SQL中的谓语条件是“t1.c1=t2.c1 and t2.c1=t3.c1”,则CBO可能会给谓语条件额外加上“t1.c1=t3.c1”。
3）外链接谓语传递
比如原目标SQL中的谓语条件是“t1.c1=t2.c1(+) and t1.c1=10”,则CBO可能会给谓语条件额外加上“t2.c1(+)=10”。
外连接：谁后面添加（+），不以谁为主表 --方便记忆
4、CBO的局限性
1）CBO会默认目标SQL语句where条件中出现的各个列之间出现是独立的，没有任何关联。并且CBO会根据这个前提条件来计算selectivity和cardinality，进而估算成本并选择执行计划。但是这种假设并不全是正确的，生产中列与列之间存在关联的现象并不罕见。目前可以用来缓解上述负面影响的方法是使用动态采样和多列统计信息。但动态采样的准确性取决于采样数据的质量以及数量，而多列统计信息并不适合用于多表之间有关联的情形，所以这两种方法只能算是缓解，并不算是完美的解决方案。
2）CBO会假设所有的目标SQL都是独立运行的，并且互不干扰，但实际情况却不完全是这样。
3）CBO对直方图统计信息有多方限制。主要体现在如下2个方面：
（1）在oracle 12c之前，frequency类型的直方图所对应的bucket的数量不能超过254，这样如果列的distinct数量超过254，oracle就会使用height balanced类型的直方图。对于height balanced类型的直方图而言，oracle不会记录所有的nonpopular value的值，所以此种情况下CBO选错执行计划的概率会比frequency类型的情形要高。
（2）在oracle数据库里，如果针对文本类型的字段手机直方图统计信息，则oracle只会将文本的前32个字符（实际只取前15个）取出来并将其转换为浮点数，然后将浮点数作为上述文本字段的直方图统计信息记录在数据字典里。
4）CBO在解析多表关联的目标SQL时，可能会漏选正确的执行计划。在oracle 11gR2中，CBO在解析这种多表关联的目标SQL时，所考虑的各个表的连接顺序的总和受隐含参数_OPTIMIZER_MAX_PERMUTATIONS的限制。这意味着目标SQL不管有多少种连接顺序，CBO最多只考虑其中根据_OPTIMIZER_MAX_PERMUTATIONS计算出来的有限种可能性。