oracle执行计划学习文档一、O racl e 执行SQL的步骤1.1、SQL 语句的两种类型DDL语句，不共享，每次执行硬解析；DML语句，会共享，硬解析或者软解析。

1.2、SQL执行步骤1、语法检测。

判断一条SQL语句的语法是否符合SQL的规范；2、语义检查。

语法正确的SQL语句在解析的第二个步骤就是判断该SQL语句所访问的表及列是否准确？用户是否有权限访问或更改相应的表或列？3、检查共享池中是否有相同的语句存在。

假如执行的SQL语句已经在共享池中存在同样的副本，那么该SQL语句将会被软解析，也就是可以重用已解析过的语句的执行计划和优化方案，可以忽略语句解析过程中最耗费资源的步骤，这也是我们为什么一直强调避免硬解析的原因。

这个步骤又可以分为两个步骤：（1）验证SQL语句是否完全一致。

（2）验证SQL语句执行环境是否相同。

比如同样一条SQL语句，一个查询会话加了/*+ first_rows */的HINT，另外一个用户加/*+ all_rows */的HINT，他们就会产生不同的执行计划，尽管他们是查询同样的数据。

通过如上三个步骤检查以后，如果SQL语句是一致的，那么就会重用原有SQL语句的执行计划和优化方案，也就是我们通常所说的软解析。

如果SQL语句没有找到同样的副本，那么就需要进行硬解析了。

4、Oracle根据提交的SQL语句再查询相应的数据对象是否有统计信息。

如果有统计信息的话，那么CBO将会使用这些统计信息产生所有可能的执行计划（可能多达成千上万个）和相应的Cost，最终选择Cost最低的那个执行计划。

如果查询的数据对象无统计信息，则按RBO的默认规则选择相应的执行计划。

这个步骤也是解析中最耗费资源的，因此我们应该极力避免硬解析的产生。

至此，解析的步骤已经全部完成，Oracle将会根据解析产生的执行计划执行SQL语句和提取相应的数据。

二、优化器介绍Oracle在执行一个SQL之前,首先要分析一下语句的执行计划,然后再按执行计划去执行。

分析语句的执行计划的工作是由优化器(Optimizer)来完成的。

不同的情况,一条SQL 可能有多种执行计划,但在某一时点,一定只有一种执行计划是最优的,花费时间是最少的。

Oracle目前提供RBO和CBO两种优化器。

2.1 RBO（RULE-BASE Optimization）基于规则的优化器RBO的执行路径和等级：1、Single Row by Rowid(等级最高)2、Single Row by Cluster Join3、Single Row by Hash Cluster Key with Unique or Primary Key4、Single Row by Unique or Primary Key5、Clustered Join6、Hash Cluster Key7、Indexed Cluster Key8、Composite Index9、Single-Column Indexes10、Bounded Range Search on Indexed Columns11、Unbounded Range Search on Indexed Columns12、Sort Merge Join13、MAX or MIN of Indexed Column14、ORDER BY on Indexed Column15、Full Table Scan(等级最低)优化器根据上述等级优先选择高效的执行路径，以上涉及到的概念在后面详细分析。

2.2 CBO（COST-BASE Optimization）基于代价的优化器Oracle把一个代价引擎集成在数据库内核，用来估计每个执行计划的代价，并量化执行计划所耗费资源，从而选择选择最优的执行计划，查询耗费资源分为以下三种。

I/0代价，即从磁盘读数据到内存的代价,从数据文件中数据块的内容读取到SGA数据高速缓存中，这是数据访问最主要的代价，故优化原则一般以降低查询产生的I/0次数为主；CPU代价，即处理在内存中数据所需代价，如对数据进行排序(sort)或者连接(join)操作等；NetWork代价，对访问跨服务器数据库的数据，需要花费的传输操作耗费的资源。

CBO 方式通过表和索引的统计数据计算出相对准确的代价，然后采用最佳的执行计划，所以定期对表和索引进行分析是非常必要的，否则得不偿失，关于数据分析技术详见第三章。

2.3 优化器模式Optimization-mode 即优化器模式，可选值包括：1、Rule ，采用的是RBO；2、CHOOSE，根据实际情况，如果数据字典中包含了引用表的统计数据，则采用CBO优化器，否则采用RBO；3、ALL-Rows是CBO使用的第一种优化方法，以数据吞吐量为目标，以便可以使用最少的资源完成查询；4、FIRST-ROWS是CBO使用的第二种优化方法，以数据的响应时间为目标，以便快速查询出开始的几行；5、FIRST-ROWS_[1|10|100|1000] 是CBO使用的第三种优化方法，选择一个响应时间最小的计划，迅速查询出结果。

2.4 查看执行计划2.4.1、查看能执行计划方式1、通过下面的sql查询：explain plan forSELECT * FROM bss_org WHERE bss_org_id=1;SELECT * FROM table(dbms_xplan.display);2、直接看pl/sql的explain Plan。

2.4.2 Estimator共 3 种度量标准：1、Selectivity表示有多少 rows 可以通过谓词被选择出来，大小介于 0.0~1.0，0 表示没有 row 被选择出来。

如果没有 statistics，estimator 会使用一个默认的 selectivity 值，这个值根据谓词的不同而异。

比如 '=' 的 selectivity 小于 '<'。

如果有statistics，比如对于last_name = 'Smith'，estimator 使用last_name 列的 distinct 值的倒数（注：是指表中所有 last_name 的 distinct 值），作为 selectivity。

如果 last_name 列上有 histogram，则使用 histogram 根据 last_name 值的分布情况产生的 selectivity 作为 selectivity。

Histogram 在当列有数据倾斜时可以大大帮助 CBO 产生好的 selectivity。

2. Cardinality表示一个 row set 的行数。

Base cardinality：base table 的行数。

如果表分析过了，则直接使用分析的统计信息。

如果没有，则使用表 extents 的数量来估计。

Effective cardinality：有效行集，指从基表中选择出来的行数。

是 Base cardinality 和表上所有谓词的组合 Selectivity 的乘积。

如果表上没有谓词，那么 Effective cardinality = Base cardinality。

Join cardinality：两表 join 后产生的行数。

是两表 cardinality 的乘积(Cartesian)乘以 Join 谓词的 selectivity。

Distinct cardinality：列上 distinct 值的行数。

Group cardinality：GROUP BY 操作之后 row set 的行数。

由 grouping columns 的distinct cardinality 和整个 row set 的行数决定。

group cardinality lies between max ( dist. card. colx , dist. card. coly ) and min ( (dist. card. colx * dist. card. coly) , num rows in row set )3. CostCost 表现了 Disk I/O, CPU usage, Memory usage 资源单位的使用数量（units of work or resource used）。

Access path 决定从 base table 获得数据所需的 units of work 的数量。

也就是说Access path 决定 Cost 的值。

Access path 可以是 table scan, fast full index scan, index scan。

Oracle10G中,优化器默认为CBO,OPTIMIZER_MODE默认值为ALL_ROWS。

不再使用古老的RBO模式,但RULE、CHOOSE并没有彻底消失,有些时候仍然可以作为我们调试的工具。

另DBMS_XPLAN.DISPLAY_CURSOR观察更为详细的执行计划。

2.5 Scan方式2.5.1、Full T able Scan 全表扫描优点：可以同时读多个数据块，减少了i/0访问次数，而且每个数据块只会被读一次。

在查询一个表>5%~10%的时候，或者想用并行查询时，可以考虑使用。

全表扫描的Hint: Full T able Scan Hints: /*+ FULL(table alias) */；2.5.2、Rowid Scans获得一行数据的最快方法。

一般要先通过index scan 获得Rowid，如果需要的列不在index 中，再进行Rowid Scans 获得相应的行，如果在index 中，则不需要Rowid Scans。

HINT（很少用到）：/*+ ROWID ( table ) */2.5.3、Index Scans1)、Index Unique Scans最多返回一个rowid，用于Unique Index 且index cols 在条件中使用"等于"。

如：SELECT * from serv where serv_id='518108574'。

2)、Index Range Scans返回的数据按照index columns 升序排列，index column 为同一个值的多行按照行rowid 的升序排列。

如果order by/group by 的顺序和Index Range Scans 返回的row set 的顺序相同就不需要再sort 了，否则还需要再对row set 进行sort。

如: SELECT * from serv where prop_cust_id='518108574'.Unique index 中的< > 条件，以及nonunique indexe 的< = > 条件，都会引起Index Range Scans。