Oracle优化器（Optimizer）是Oracle在执行SQL之前分析语句的工具。
Oracle的优化器有两种优化方式：
基于规则的优化方式：Rule-Based Optimization（RBO）
优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。比如我们常见的，当一个where子句中的一列有索引时去走索引。
基于成本或者统计信息的优化方式(Cost-Based Optimization：CBO)
CBO是在ORACLE7 引入，但到ORACLE8i 中才成熟。ORACLE 已经声明在ORACLE9i之后的版本中，RBO将不再支持。它是看语句的代价(Cost),这里的代价主要指Cpu和内存。CPU Costing的计算方式现在默认为CPU+I/O两者之和.可通过DBMS_XPLAN.DISPLAY_CURSOR观察更为详细的执行计划。优化器在判断是否用这种方式时,主要参照的是表及索引的统计信息。统计信息给出表的大小、有少行、每行的长度等信息。这些统计信息起初在库内是没有的，是做analyze后才出现的，很多的时侯过期统计信息会令优化器做出一个错误的执行计划,因些应及时更新这些信息。按理，CBO应该自动收集，
实际却不然，有时候在CBO情况下，还必须定期对大表进行分析。
Oracle优化器的优化模式：
1)      CHOOSE
仅在9i及之前版本中被支持，10g已经废除。8i及9i中为默认值。
这个值表示SQL语句既可以使用RBO优化器也可以使用CBO优化器，而决定该SQL到底使用哪个优化器的唯一因素是，所访问的对象是否存在统计信息。如果所访问的全部对象都存在统计信息，则使用CBO优化器优化SQL；如果只有部分对象存在统计信息，也仍然使用CBO优化器优化SQL，优化器会为不存在统计信息对象依据一些内在信息（如分配给该对象的数据块）来生成统计信息，只是这样生成的统计信息可能不准确，而导致产生不理想的执行计划；如果全部对象都无统计信息，则使用RBO来优化该SQL语句。
2)      RULE
仅在9i及之前版本中被支持，10g已经废除。
不论是否存在统计信息，都将使用RBO优化器来优化SQL。
3)      ALL_ROWS
在10g中为默认值。
不论是否存在统计信息，都使用CBO优化器，且把CBO的优化目标设定为“最小的成本”。
4)      FIRST_ROWS
CBO尽可能快速的返回结果集的前面少数行记录。
不论是否存在统计信息，都使用CBO优化器，FIRST_ROWS导致CBO使用“试探法”来产生执行计划，这种方式其成本可能会稍大一些。
5)      FIRST_ROWS_n
不论是否存在统计信息，都使用CBO优化器，并以最快的速度返回前n行记录，n可以是1,10,100,1000。
优化器只有2种，使用不同的优化模式可以指定优化器。
首先，默认的优化模式是Choose，文章建议我们避免使用Choose模式。
然后，Oracle对RBO优化器的支持只到9IR2，也就是说从Oracle10开始，RBO就不存在了，但是仍然可以用HINTS来使用RBO模式。
如何查看正在使用的模式：show parameter optimizer_mode
修改使用的优化模式的方法：
1)      Instance级别：在init<SID>.ora文件中设定OPTIMIZER_MODE；
2)      Session级别：通过SQL> ALTER SESSION SET OPTIMIZER_MODE=;来设定。
3)      语句级别：通过SQL> SELECT /*+ALL+_ROWS*/ ……;来设定。可用的HINT包括/*+ALL_ROWS*/、/*+FIRST_ROWS*/、/*+CHOOSE*/、/*+RULE*/ 等。
要注意的是，如果表有统计信息，则可能造成语句不走索引的结果。可以用
SQL>ANALYZE TABLE table_name DELETE STATISTICS;
删除统计信息。
对列和索引更新统计信息的SQL：
SQL> ANALYZE TABLE table_name COMPUTE STATISTICS;
SQL> ANALYZE INDEX index_name ESTIMATE STATISTICS;
FIRST_ROWS（n） 模式说明
当CBO 的优化模式设置为FIRST_ROWS（n）时，Oracle 在执行SQL时，优先考虑将结果集中的前n条记录以最快的速度反馈回来，而其他的结果并不需要同时返回。
这种需求在一些网站或者BBS的分页上经常看到，比如每次只显示查询信息的前20条或者BBS上的前20个帖子，这时候设置FIRST_ROWS（20）就非常合适，优化器并不需要同事将所有符合条件的结果返回，用户也不需要。这时，CBO将考虑用一种最快的返回前20条记录的执行计划，这种执行计划对于SQL的整体执行时间也不不是最快的，但是在返回
前20条记录的处理上，确实最快的。
ALL_ROWS 模式说明
当CBO 模式设置为ALL_ROWS时，Oracle 会用最快的速度将SQL执行完毕，将结果集全部返回，它和FIRST_ROWS（n）的区别在于，ALL_ROWS强调以最快的速度将SQL执行完毕，并将所有的结果集反馈回来，而FIRST_ROWS（n）则侧重于返回前n条记录的执行时间。
ALL_ROWS在OLAP 系统中使用得比较多，它用最快的速度获得SQL执行的最后一条记录，而不是前N条记录。 和FIRST_ROWS（n）正好相反。 ALL_ROWS 强调SQL整体的执行效率，而FIRST_ROWS（n）强调用最快的速度返回前N行，而不管所有的结果返回的时长，可能最后一条要很长时间才能获得。
在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个表，则其可选择的连接顺序就是12*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掌握了充分反映实际的统计数据，才有可能做出正确的选择。
sql语句优化方式
10、使用CBO 时，要注意被索引的字段的值的数据分布，会影响SQL语句的执行计划。例如：表emp，共有一百万行数据，但其中的emp.deptno列，数据只有4种不同的值，如10、20、30、40。虽然emp数据行有很多，ORACLE缺省认定表中列的值是在所有数据行均匀分布的，也就是说每种deptno值各有25万数据行与之对应。假设SQL搜索条件DEPTNO=10，利用deptno列上的索引进行数据搜索效率，往往不比全表扫描的高，ORACLE理所当然对索引“视而不见”，认为该索引的选择性不高。
我们考虑另一种情况，如果一百万数据行实际不是在4种deptno值间平均分配，其中有99万行对应着值10，5000行对应值20，3000行对应值30，2000行对应值40。在这种数据分布图案中对除值为10外的其它deptno值搜索时，毫无疑问，如果索引能被应用，那么效率会高出很多。我们可以采用对该索引列进行单独分析，或用analyze语句对该列建立直方图，对该列搜集足够的统计数据，使ORACLE在搜索选择性较高的值能用上索引。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。