本文共 6031 字，大约阅读时间需要 20 分钟。
Oracle优化器介绍
Oracle数据库中的优化器又叫查询优化器（Query Optimizer）。它是SQL分析和执行的优化工具，它负责生成、制定SQL的执行计划。也就是它负责保证SQL的执行计划的效率最高，比如优化器决定Oracle以什么样的方式访问数据，优化器是SQL执行的核心，它作出的执行计划的好坏，直接影响着SQL的执行效率。Oracle的优化器有两种，基于规则的优化器（RBO）与基于代价的优化器（CBO)。
CBO是一种比RBO更加合理、可靠的优化器，它是从ORACLE 8中开始引入，但到ORACLE 9i 中才逐渐成熟，在ORACLE 10g中完全取代RBO， CBO是计算各种可能“执行计划”的“代价”，即COST，从中选用COST最低的执行方案，作为实际运行方案。它依赖数据库对象的统计信息，统计信息的准确与否会影响CBO做出最优的选择。如果对一次执行SQL时发现涉及对象（表、索引等）没有被分析、统计过，那么ORACLE会采用一种叫做动态采样的技术，动态的收集表和索引上的一些数据信息。
关于RBO与CBO，我有个形象的比喻：大数据时代到来以前，做生意或许凭借多年累计下来的经验（RBO）就能够很好的做出决策，跟随市场变化。但是大数据时代，如果做生意还是靠以前凭经验做决策，而不是靠大数据、数据分析、数据挖掘做决策，那么就有可能做出错误的决策。这也就是越来越多的公司对BI、数据挖掘越来越重视的缘故，像电商、游戏、电信等行业都已经大规模的应用，以前在一家游戏公司数据库部门做BI分析，挖掘潜在消费用户简直无所不及。至今映像颇深。
RBO优化器
Rule-Based Optimization 基于规则的优化器，随着CBO优化器的逐步发展和完善，在最新的10g版本中Oracle已经彻底废除了RBO。正在使用Oracle8i或9i的人们或多或少的都会碰到RBO，因此在详细介绍CBO之前，我们有必要简单回顾一下古老的RBO优化器。
在RBO中Oracle根据可用的访问路径和访问路径的等级来选择执行计划，等级越高的访问路径通常运行SQL越慢，如果一个语句有多个路径可走，Oracle总是选择等级较低的访问路径。
RBO访问路径
1级：用Rowid定位单行
当WHERE子句中直接嵌入Rowid时，RBO走此路径。Oracle不推荐直接引用Rowid，Rowid可能会由于版本的改变而变化，行迁移、行链接、EXP/IMP也会使Rowid发生变化。
2级：用Cluster Join定位单行
两个表做等值连接，一方的连接字段是Cluster Key，且WHERE中存在可以保证该语句仅返回一行记录的条件时，RBO走此路径。
3级：用带用唯一约束或做主键的Hash Cluster Key定位单行
4级：用唯一约束的字段或做主键的字段来定位单行
5级：Cluster Join
6级：使用Hash Cluster Key
7级：使用索引Cluster Key
8级：使用复合索引
9级：使用单字段索引
10级：用索引进行有界限范围的查找
如，column >[=] expr AND column <[=] expr或column BETWEEN expr AND expr
或column LIKE ‘c%’
11级：用索引字段进行无界限的查找
如，WHERE column >[=] expr 或 WHERE column <[=] expr
12级：排序合并连接
13级：对索引字段使用MAX或MIN函数
14级：ORDER BY索引字段
15级：全表扫描
如果可以使用索引RBO会尽可能的去用索引而不是全表扫描，但是在下列一些情况RBO只能使用全表扫描：
如果column1和column2是同一个表的字段，含有条件column1 < column2或column1 > column2或column1 <= column2或column1 >= column2，RBO会用全表扫描。
如果使用column IS NULL或column IS NOT NULL或column NOT IN或column != expr或column LIKE ‘%ABC’时，不论column有无索引，RBO都使用全表扫描。
如果expr = expr2，expr表达式作用了一个字段上，无论该字段有无索引，RBO都会全表扫描。
NOT EXISTS子查询以及在视图中使用ROWNUM也会造成RBO进行全表扫描。
以上就是RBO的全部可用访问路径。RBO优化器死板的根据规则来选择执行计划显然不够灵活，在RBO中也无法使用物化视图等Oracle提供的新特性，在Oracle8i时CBO已经基本成熟，因此Oracle强烈建议改用CBO优化器。下文将全面介绍CBO优化器。
CBO优化器结构Cost-Based Optimization 基于代价的优化器，它根据可用的访问路径、对象的统计信息、嵌入的Hints来选择一个成本最低的执行计划。
CBO主要包含以下组件：
- l 查询转换器（Query Transformer）
- l 评估器（Estimator）
- l 计划生成器（Plan Generator）
如下图所示：
查询转换器
查询语句的形式会影响所产生的执行计划，查询转换器的作用是等价改变查询语句的形式，以便产生更好的执行计划。它决定是否重写用户的查询（包括视图合并（View Merging）、谓词推进（Predicate Pushing）、非嵌套子查询（Subquery Unnesting）和物化视图的查询重写（Query Rewrite with Materialized Views）），以生成更好的查询计划
视图合并：如果SQL语句中含有视图，经分析后会把视图放在独立的“视图查询块”中，每个视图会产生一个视图子计划，当为整个语句产生执行计划时，视图子计划会被直接拿来使用而不会照顾到语句的整体性，这样就很容易导致不良执行计划的生成。视图合并就是为了去掉“视图查询块”，将视图合并到一个整体的查询块中，这样就不会有视图子计划产生，执行计划的优良性得到提升。
谓词推进：不是所有的视图都能够被合并，对于那些不能被合并的视图Oracle会将相应的谓词推进到视图查询块中，这些谓词通常是可索引的或者是过滤性较强的。
非嵌套子查询：子查询和视图一样也是被放于独立查询块中的，查询转换器会将绝大多数子查询转换为连接从而合并为同一查询块，少量不能被转换为连接的子查询，会将它们的子计划安照一个高效的方式排列。
物化视图的查询重写：当query_rewrite_enabled=true时，查询转换器寻找与该查询语句相关联的物化视图，并用物化视图改写该查询语句。
关于“窥视”（Peeking）:
在Oracle9i中为查询转换器增加了一个功能，就是当用户使用绑定变量时，查询转换器可以“偷窥”绑定变量的实际值。
我们知道使用绑定变量虽然可以有效的减少“硬分析”，但它带来的负面影响是优化器无法根据实际的数据分布来优化SQL，很有可能本可以走索引的SQL却做了全表扫描。“窥视”正是为了解决这个问题，但是它并没有彻底的解决，Oracle只允许第一次调用时进行“窥视”，接下来的调用即使绑定变量的值发生了变化，也仍然是使用第一次生成的执行计划，这就造成了一个错误的执行计划会被多次使用，10g中的“窥视”也是如此。
评估器
评估器通过复杂的算法结合统计信息的三个值来评估各个执行计划的总体成本：选择性（Selectivity）、基数（Cardinality）、成本（Cost）
计划生成器会考虑可能的访问路径（Access Path）、关联方法和关联顺序，生成不同的执行计划，让查询优化器从这些计划中选择出执行代价最小的一个计划。
选择性：是一个大于0小于1的数，0表示没有记录被选定，1表示所有记录都被选定。统计信息和直方图关系到选择性值的准确性。如：name=’Davis’，如果不存在统计信息评估器将根据所用的谓词来指定一个缺省的选择性值，此时评估器会始终认为等式谓词的选择性比不等式谓词小；如果存在统计信息而不存在直方图，此时选择性值为1/count(distinct name)；如果存在统计信息也存在直方图，选择性值则为count（name）where name=’Davis’ / count（name）where name is not null。
基数：通常表中的行数称为“基础基数”（Base cardinality）；当用WHERE中的条件过滤后剩下的行数称为“有效基数”（Effective cardinality）；连接操作之后产生的结果集行数称为“连接基数”（Join cardinality）；一个字段DISTINCT之后的行数称为“DISTINCT基数”；“GROUP基数”（Group cardinality）比较特殊，它与基础基数和DISTINCT基数有关，例如：group by colx则GROUP基数就等于基础基数，但是group by colx,coly的GROUP基数则大于max ( distinct cardinality of colx , distinct cardinality of coly )且小于min ( (distinct cardinality of colx * distinct cardinality of coly) , base cardinality)。
成本：就是度量资源消耗的单位。可以理解为执行表扫描、索引扫描、连接、排序等操作所消耗I/O、CPU、内存的数量。
计划生成器
计划生成器的作用就是生成大量的执行计划，然后选择其中总体成本最低的一个。
由于不同的访问路径、连接方式和连接顺序可以任意组合，虽然以不同的方式访问和处理数据，但是可以产生同样的结果，因此一个SQL可能存在大量不同的执行计划。但实际上计划生成器很少会试验所有的可能存在的执行计划，如果它发现当前执行计划的成本已经很低了，它将停止试验，相反当前计划的成本如果很高，它将继续试验其他执行计划，因此如果能使计划生成器一开始就找到成本很低的执行计划，则会大量减少所消耗的时间，这也正是我们为什么用HINTS来优化SQL的原因之一。
查看ORACLE优化器
SQL> show parameter optimizer_mode; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ optimizer_mode string CHOOSE SQL>
修改ORACLE优化器
ORACLE 10g 优化器可以从系统级别、会话级别、语句级别三种方式修改优化器模式，非常方便灵活。
其中optimizer_mode可以选择的值有： first_rows_n,all_rows. 其中first_rows_n又有first_rows_1000, first_rows_100, first_rows_10, first_rows_1
在Oracle 9i中，优化器模式可以选择first_rows_n,all_rows, choose, rule 等模式：
Rule： 基于规则的方式。
Choose：指的是当一个表或或索引有统计信息，则走CBO的方式，如果表或索引没统计信息，表又不是特别的小，而且相应的列有索引时，那么就走索引，走RBO的方式，默认的方式是choose。
If OPTIMIZER_MODE=CHOOSE, if statistics do not exist, and if you do not add hints to SQL statements, then SQL statements use the RBO. You can use the RBO to access both relational data and object types. If OPTIMIZER_MODE=FIRST_ROWS, FIRST_ROWS_n, or ALL_ROWS and no statistics exist, then the CBO uses default statistics. Migrate existing applications to use the cost-based approach.
First Rows：它与Choose方式是类似的，所不同的是当一个表有统计信息时，它将是以最快的方式返回查询的最先的几行，从总体上减少了响应时间。
All Rows: 10g中的默认值，也就是我们所说的Cost的方式，当一个表有统计信息时，它将以最快的方式返回表的所有的行，从总体上提高查询的吞吐
虽然Oracle 10g中不再支持RBO，Oracle 10g官方文档关于optimizer_mode参数的只有first_rows和all_rows.但是依然可以设置 optimizer_mode为rule或choose，估计是ORACLE为了过渡或向下兼容考虑。
系统级别
SQL> alter system set optimizer_mode=rule scope=both;
System altered.
SQL> show parameter optimizer_mode
NAME TYPE VALUE
-------------------------------- ----------- -----------------------
optimizer_mode string RULE会话级别
SQL> alter session set optimizer_mode=first_rows_100;
Session altered.
语句级别
语句级别通过使用提示hints来实现。
SQL> select /*+ rule */ * from dba_objects where rownum <= 10;
本文参照：http://www.cnblogs.com/kerrycode/p/3842215.html
http://www.cnblogs.com/dongzhiquan/archive/2012/01/20/2328365.html