一、Oracle的优化器有两种优化方式：
Oracle支持两种不同的查询优化器：CBO和RBO。
在Oracle数据库中，CBO（Cost-Based Optimizer）更容易走索引，而RBO（Rule-Based Optimizer）则使用一组固定的规则来选择执行计划，可能不太主动地选择使用索引。
1、基于规则的优化方式(Rule-Based Optimization，简称为RBO)
优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则，对数据是不敏感。它只借助少量的信息来决定一个sql语句的执行计划，包括：
1）sql语句本身 2）sql中涉及到的table、view、index等的基本信息 3）本地数据库中数据字典中的信息（远程数据库数据字典信息对RBO是无效的）
例如：我们常见的，当一个where子句中的一列有索引时去走索引。但是需要注意，走索引不一定就是优的，比如一个表只有两行数据，一次IO就可以完成全表的检索,而此时走索引时则需要两次IO,这时全表扫描(full table scan)的效率更优。
2、基于代价的优化方式(Cost-Based Optimization，简称为CBO)
它是看语句的代价(Cost),通过代价引擎来估计每个执行计划所需的代价，该代价将每个执行计划所耗费的资源进行量化，CBO根据这个代价选择出最优的执行计划。
一个查询所耗费的资源可分为三部分：I/O代价、CPU代价、NETWORK代价。
--I/O是指把数据从磁盘读入内存时所需代价（该代价是查询所需最主要的，所以在优化时一个基本原则就是降低I/O总次数）； --CPU代价是指处理内存中数据所需的代价，数据一旦读入内存，当我们识别出我们所要的数据后，会在这些数据上执行排序（sort）或连接（join）操作，这需要消耗CPU资源； --对于访问远程节点来说，network代价的花费也是很大的。
优化器在判断是否用这种方式时，主要参照的是表及索引的统计信息。统计信息给出表的大小、有多少行、每行的长度等信息。
这些统计信息起初在库内是没有的，是做analyze后才出现的，很多的时侯过期统计信息会令优化器做出一个错误的执行计划,因些应及时更新这些信息（dbms_stat.analyze）。
如星型连接排列查询，哈希连接查询，函数索引，和并行查询等一些技术都是基于CBD的。
CBO方式：CBO是在ORACLE7 引入，但到ORACLE8i 中才成熟。ORACLE 已经声明在ORACLE9i之后的版本中，RBO将不再支持。它是看语句的代价（Cost），这里的代价主要指Cpu和内存。CPU Costing的计算方式现在默认为CPU+I/O两者之和。可通过DBMS_XPLAN.DISPLAY_CURSOR观察更为详细的执行计划。优化器在判断是否用这种方式时，主要参照的是表及索引的统计信息。统计信息给出表的大小、有少行、每行的长度等信息。这些统计信息起初在库内是没有的，是做analyze后才出现的，很多的时侯过期统计信息会令优化器做出一个错误的执行计划，因些应及时更新这些信息。按理，CBO应该自动收集，实际却不然，有时候在CBO情况下，还必须定期对大表进行分析。
注意：走索引不一定就是优的，比如一个表只有两行数据，一次IO就可以完成全表的检索，而此时走索引时则需要两次IO,这时全表扫描（full table scan）是最好。
3、Oracle数据库可以选择的模式：
Oracle使用Optimizer_mode参数来控制优化器的偏好，9i常用的几个参数有：first_rows,all_rows,first_rows_N，rule,choose等。而10g少了rule和choose。
优化模式包括Rule、Choose、First rows、All rows四种方式：
Rule： 基于规则的方式。
Choose： 默认的情况下Oracle用的便是这种方式。指的是当一个表或或索引有统计信息，则走CBO的方式，
如果表或索引没统计信息，表又不是特别的小，而且相应的列有索引时，那么就走索引，走RBO的方式。
First Rows： 它与Choose方式是类似的，所不同的是当一个表有统计信息时，它将是以最快的方式返回查询的最先的几行，从总体上减少了响应时间。
All Rows: 也就是我们所说的Cost的方式，当一个表有统计信息时，它将以最快的方式返回表的所有的行，从总体上提高查询的吞吐量。没有统计信息则走RBO的方式。
4、设定选用哪种优化模式：
A、在initSID.ora中设定OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS（默认是Choose）
选择方式：在optimizer_mode=choose时,如果表有统计信息(分区表外),优化器将选择CBO,否则选RBO。
B、Sessions级别通过：
ALTER SESSION SET OPTIMIZER_MODE=RULE/CHOOSE/FIRST_ROWS/ALL_ROWS
C、语句级别用Hint（/*+ ... */）来设定
5、一些常见的问题：
（1）为什么表的某个字段明明有索引，但执行计划却不走索引？
1、优化模式是all_rows的方式
2、表做过analyze，有统计信息
3、表很小，上文提到过的，Oracle的优化器认为不值得走索引。
（2）使用CBO时，SQL语句中为什么不能引用系统数据字典表或视图？
1、因为系统数据字典表都未被分析过，可能导致极差的“执行计划”。 2、擅自对数据字典表做分析，可能导致死锁，或系统性能严重下降。
（3）使用CBO时如何选择表连接方式？(执行计划中包含：SMJ,NL,HJ三种连接方式）
1、CBO有时会偏重于SMJ和HJ，但在OLTP系统中，NL一般会更好，因为它高效的使用了索引。 2、SMJ即使相关列上建有索引，最多只能因索引的存在，避免数据排序过程。 3、HJ由于须做HASH运算，索引的存在对数据查询速度几乎没有影响。
（4）使用CBO时，需要注意什么吗？
1、必须保证为表和相关的索引搜集足够的统计数据，对数据经常有增、删、改的表最好定期对表和索引进行分析
2、可用SQL语句：
analyze table xxx compute statistics for all indexes
或：
begin
dbms_stats.gather_table_stats(ownname => 'TEST',tabname => 'TEST' );
end;
（5）为什么有时使用CBO会比较慢？
1、没有对表或视图进行Analyze 2、SQL进行CBO时对于没有Analyze的对象会自动进行Analyze，因此造成运行慢
6、在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掌握了充分反映实际的统计数据，才有可能做出正确的选择。
（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在搜索选择性较高的值能用上索引。
