ORACLE优化器与执行顺序

今天查了一些资料，关于在ORACLE中，where后的条件的执行顺序与性能的影响，现在总结如下：

1.oracle中，条件的解析是从右到左的。

2.RBO优化器对于顺序要求较高，过滤较多数据的条件在右面的时候，性能较高。

  而CBO优化器则是基于统计，选择最优的执行计划。

参考资料如下：

 

ORACLE 提供了CBO、RBO两种SQL优化器

ORACLE 提供了CBO、RBO两种SQL优化器。CBO在ORACLE7 引入，但在ORACLE8i 中才成熟。ORACLE 已经明确声明在ORACLE9i之后的版本中(ORACLE 10G )，RBO将不再支持。因此选择CBO 是必然的趋势。

     CBO和 RBO作为不同的SQL优化器，对SQL语句的执行计划产生重大影响，如果要对现有的应用程序从RBO向CBO移植，则必须充分考虑这些影响，避免SQL语句性能急剧下降；但是，对新的应用系统，则可以考虑直接使用CBO，在CBO模式下进行SQL语句编写、分析执行计划、性能测试等工作，这需要开发者对CBO的特性比较熟悉。

以下小结几点在CBO下写SQL语句的注意事项：

1、RBO自ORACLE 6版以来被采用，有着一套严格的使用规则，只要你按照它去写SQL语句，无论数据表中的内容怎样，也不会影响到你的“执行计划”，也就是说对数据不“敏 感”；CBO计算各种可能“执行计划”的“代价”，即cost，从中选用cost最低的方案，作为实际运行方案。各“执行计划”的cost的计算根据，依 赖于数据表中数据的统计分布，ORACLE数据库本身对该统计分布并不清楚，必须要分析表和相关的索引（使用ANALYZE 命令），才能搜集到CBO所需的数据。

2、使用CBO 时，编写SQL语句时，不必考虑"FROM" 子句后面的表或视图的顺序和"WHERE" 子句后面的条件顺序；ORACLE自7版以来采用的许多新技术都是基于CBO的，如星型连接排列查询，哈希连接查询，函数索引，和并行查询等。

3、一般而言，CBO所选择的“执行计划”都不会比RBO的“执行计划”差，而且相对而言，CBO对程序员的要求没有RBO那么苛刻，节省了程序员为了从多个可能的“执行计划”中选择一个最优的方案而花费的调试时间，但在某些场合下也会存在问题。
      较典型的问题有：有时，表明明建有索引，但查询过程显然没有用到相关的索引，导致查询过程耗时漫长，占用资源巨大，这时就需要仔细分析执行计划，找出原 因。例如，可以看连接顺序是否允许使用相关索引。假设表emp的deptno列上有索引，表dept的列deptno上无索引，WHERE语句有 emp.deptno=dept.deptno条件。在做NL连接时，emp做为外表，先被访问，由于连接机制原因，外表的数据访问方式是全表扫 描，emp.deptno上的索引显然是用不上，最多在其上做索引全扫描或索引快速全扫描。

4、如果一个语句使用 RBO的执行计划确实比CBO 好，则可以通过加 " rule" 提示，强制使用RBO。

5、使用CBO 时，SQL语句 "FROM" 子句后面的表，必须全部使用ANALYZE 命令分析过，如果"FROM" 子句后面的是视图，则此视图的基础表，也必须全部使用ANALYZE 命令分析过；否则，ORACLE 会在执行此SQL语句之前，自动进行ANALYZE 命令分析，这会极大导致SQL语句执行极其缓慢。

6、使用CBO 时，SQL语句 "FROM" 子句后面的表的个数不宜太多，因为CBO在选择表连接顺序时，会对"FROM" 子句后面的表进行阶乘运算，选择最好的一个连接顺序。假如"FROM" 子句后有6个表，则其可选择的连接顺序就是6*5*4*3*2*1 = 720 种，CBO 选择其中一种，而如果"FROM" 子句后有12个表，则其可选择的连接顺序就是2*11*10*9*8*7*6*5*4*3*2*1= 479001600 种，可以想象从中选择一种，会消耗多少CPU 时间？如果实在是要访问很多表，则最好使用 ORDER 提示，强制使用"FROM" 子句表固定的访问顺序。

7、使用CBO 时，SQL语句中不能引用系统数据字典表或视图，因为系统数据字典表都未被分析过，可能导致极差的“执行计划”。但是不要擅自对数据字典表做分析，否则可能导致死锁，或系统性能严重下降。

8、使用CBO 时，要注意看采用了哪种类型的表连接方式。ORACLE的共有Sort Merge Join（SMJ）、Hash Join（HJ）和Nested Loop Join（NL）。CBO有时会偏重于SMJ 和 HJ，但在OLTP 系统中，NL 一般会更好，因为它高效的使用了索引。
      在两张表连接，且内表的目标列上建有索引时，只有Nested Loop才能有效地利用到该索引。SMJ即使相关列上建有索引，最多只能因索引的存在，避免数据排序过程。HJ由于须做HASH运算，索引的存在对数据查询速度几乎没有影响。

9、使用CBO 时，必须保证为表和相关的索引搜集足够的统计数据。对数据经常有增、删、改的表最好定期对表和索引进行分析，可用SQL语句“analyze table xxx compute statistics for all indexes;"ORACLE掌握了充分反映实际的统计数据，才有可能做出正确的选择。

10、使用CBO 时，要注意被索引的字段的值的数据分布，会影响SQL语句的执行计划。例如：表emp，共有一百万行数据，但其中的emp.deptno列，数据只有4种 不同的值，如10、20、30、40。虽然emp数据行有很多，ORACLE缺省认定表中列的值是在所有数据行均匀分布的，也就是说每种deptno值各 有25万数据行与之对应。假设SQL搜索条件DEPTNO=10，利用eptno列上的索引进行数据搜索效率，往往不比全表扫描的高，ORACLE理所当 然对索引“视而不见”，认为该索引的选择性不高。

　　我们考虑另一种情况，如果一百万数据行实际不是在4种deptno值间平均分配，其中有99万行对应着值10，5000行对应值20，3000行对应 值30，2000行对应值40。在这种数据分布图案中对除值为10外的其它deptno值搜索时，毫无疑问，如果索引能被应用，那么效率会高出很多。我们 可以采用对该索引列进行单独分析，或用analyze语句对该列建立直方图，对该列搜集足够的统计数据，使ORACLE在搜索选择性较高的值能用上索引。

 

Oracle sql语句执行顺序

 

sql语法的分析是从右到左

 

一、sql语句的执行步骤：
1）语法分析，分析语句的语法是否符合规范，衡量语句中各表达式的意义。
2）语义分析，检查语句中涉及的所有数据库对象是否存在，且用户有相应的权限。
3）视图转换，将涉及视图的查询语句转换为相应的对基表查询语句。
4）表达式转换， 将复杂的 SQL 表达式转换为较简单的等效连接表达式。
5）选择优化器，不同的优化器一般产生不同的“执行计划”
6）选择连接方式， ORACLE 有三种连接方式，对多表连接 ORACLE 可选择适当的连接方式。
7）选择连接顺序， 对多表连接 ORACLE 选择哪一对表先连接，选择这两表中哪个表做为源数据表。
8）选择数据的搜索路径，根据以上条件选择合适的数据搜索路径，如是选用全表搜索还是利用索引或是其他的方式。
9）运行“执行计划”

 

二、oracle 共享原理：
     ORACLE将执行过的SQL语句存放在内存的共享池(shared buffer pool)中，可以被所有的数据库用户共享。

当你执行一个SQL语句(有时被称为一个游标)时，如果它和之前的执行过的语句完全相同，ORACLE就能很快获得已经被解析的语句以及最好的执行路径.。这个功能大大地提高了SQL的执行性能并节省了内存的使用。

 

三、oracle 语句提高查询效率的方法：

1：where column in(select * from ... where ...);

2：... where exists (select 'X' from ...where ...);

 

第二种格式要远比第一种格式的效率高。

 

在Oracle中可以几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。

使用EXIST，Oracle系统会首先检查主查询，然后运行子查询直到它找到第一个匹配项，

这就节省了时间Oracle系统在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在在一个加了索引的临时表中。

 

避免使用having子句。HAVING 只会在检索出所有记录之后才对结果集进行过滤。

这个处理需要排序，总计等操作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。

 

四、SQL Select语句完整的执行顺序： 

1、from子句组装来自不同数据源的数据；
2、where子句基于指定的条件对记录行进行筛选；
3、group by子句将数据划分为多个分组；
4、使用聚集函数进行计算；
5、使用having子句筛选分组；
6、计算所有的表达式；
7、select 的字段；

8、使用order by对结果集进行排序。

SQL语言 不同于其他编程语言的最明显特征是处理代码的顺序。在大多数据库语言中，代码按编码顺序被处理。但在SQL语句中，第一个被处理的子句式FROM，而不是第一出现的SELECT。SQL 查询处理的步骤序号：

(8) 

1 SELECT  (9) DISTINCT (11) <TOP_specification> <select_list> 

2  (1)  FROM <left_table>  

3  (3) <join_type> JOIN <right_table> 

4  (2) ON <join_condition> 

5  (4) WHERE <where_condition> 

6  (5) GROUP BY <group_by_list> 

7  (6) WITH {CUBE | ROLLUP} 

8  (7) HAVING <having_condition> 

9 (10) ORDER BY <order_by_list>

　　以上每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只有最后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句，将跳过相应的步骤。

　　逻辑查询处理阶段简介：

　　1、 FROM：对FROM子句中的前两个表执行笛卡尔积(交叉联接)，生成虚拟表VT1。

　　2、 ON：对VT1应用ON筛选器，只有那些使为真才被插入到TV2。

　　3、 OUTER (JOIN):如果指定了OUTER JOIN(相对于CROSS JOIN或INNER JOIN)，保留表中未找到匹配的行将作为外部行添加到VT2，生成TV3。如果FROM子句包含两个以上的表，则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3，直到处理完所有的表位置。

　　4、 WHERE：对TV3应用WHERE筛选器，只有使为true的行才插入TV4。

　　5、 GROUP BY：按GROUP BY子句中的列列表对TV4中的行进行分组，生成TV5。

　　6、 CUTE|ROLLUP：把超组插入VT5，生成VT6。

　　7、 HAVING：对VT6应用HAVING筛选器，只有使为true的组插入到VT7。

　　8、 SELECT：处理SELECT列表，产生VT8。

　　9、 DISTINCT：将重复的行从VT8中删除，产品VT9。

　　10、ORDER BY：将VT9中的行按ORDER BY子句中的列列表顺序，生成一个游标(VC10)。

    11、TOP：从VC10的开始处选择指定数量或比例的行，生成表TV11，并返回给调用者。