oracle optimization study notes -----

Chapter One: oracle optimizer

1. optimizer: when an Oracle database optimizer built into a core subsystems.

Category 2: oracle database optimizer into RBO and CBO, (Rule-Based-Optimizer ) rule-based optimizer , (Cost-Based-Optimizer) based on the cost of the Optimizer

3.RBO level from low to high level is divided into 1 to 15, 1 is the highest efficiency, the lowest level 15, the RBO built level corresponding to a single row by performing path ROWID execution path, the corresponding level for the full 15 table scan (full table scan).

4.CBO compared with RBO, there are obvious defects, in the case of the use of RBO, the execution plan if there are problems, it is difficult to make adjustments, there is, SQL wording, even when the target SQL various objects involved in the SQL text of the order, may affect the choice of the RBO SQL execution plan, as well as, oracle database has a lot of nice features are not supported RBO.

5. Adjust the RBO, changing the execution plan, where such conditions, or for NUMBER DATE type column plus 0, varchar2 char type or a space character, if you encounter the same level of SQL, RBO will e.g. '||', SQL caching target sequence and the sequence in the data dictionary cache in each object involved appear in the target SQL text to comprehensive judgments based on relevant objects in the target SQL involved, it means that we can adjust the related objects in the data dictionary cache caching order, change the order of individual objects SQL involved in the SQL text that appears to adjust its implementation plan.

6. Do sql 

create index idx_mgr_temp on emp_temp(mgr); 

create index idx_deptno_temp on emp_temp(deptno);   

select * from emp_temp where mgr > 100 and deptno > 100 ;

From the figure can be seen taking the index is idx_deptno_temp, go rule is RBO.

If we go idx_deptno_temp found no idx_mgr_temp high efficiency index, we can change the SQL statement is executed

select * from emp_temp where mgr > 100 and deptno+0 > 100 ;

From the figure below, the index has been taking idx_mgr_temp.

Before we create is idx_mgr_temp, and then create a idx_deptno_temp, the order of the data dictionary cache is idx_mgr_temp, then idx_deptno_temp, in this case, RBO taking idx_deptno_temp, delete the index idx_mgr_temp, re-create the index idx_mgr_temp, this time , dictionary data buffer becomes idx_deptno_temp, then idx_mgr_temp, the SQL performed at this time, the index can be found go into a idx_mgr_temp, when executing instructions to select two of the same level, can be changed by changing RBO dictionary data for which the cache sequence select program.

select * from emp_temp where mgr > 100 and deptno > 100 ;

Mentioned earlier, we can also adjust the target SQL execution plan by changing the order of the objects involved in SQL appear in the SQL text, which is usually applied to the case of multi-table appearance of the associated target sql, the target appears in the sql when the same execution path level value, RBO will be decided in accordance with the order from right to left who is driving the table, who is the driver table, and then select the execution plan.

Execute sql:

select t1.mgr ,t2.deptno from emp_temp t1, emp_temp1 t2 where t1.empno = t2.empno;

Provided: TABLE emp_temp emp_temp1 unique table and connection conditions t1.empno = t2.empno, and fields in the table emp_temp empno emp_temp1 are no indexes

此时,RBO会选择emp_temp1为驱动表,更换位置,则驱动表变成了emp_temp

select t1.mgr,t2.deptno from emp_temp1 t2,emp_temp t1 where t1.empno = t2.empno;

如果RBO仅凭各条执行路径等级值的大小选择目标SQL的执行计划,那么无论如何调整相关对象在该SQL的SQL文本中的位置,对于该SQL最终的执行计划都不会有影响。

执行sql:

前提:表emp与表emp_temp唯一的表连接条件为t1.empno=t2.empno,对于表emp而言,列empno中存在主键索引,对于表emp_temp而言,列empno不存在任何索引。

select * from emp t1, emp_temp t2  where t1.empno=t2.empno

此时驱动表是emp_temp

改变目标sql中对象的位置

select * from emp_temp t2, emp t1 where t1.empno=t2.empno

此时驱动表并不会改变。

 7.基于成本的优化器

RBO是有明显区别的,RBO最大的问题在于它是靠硬编码在oracle数据库代码的一系列固定的规则来决定目标SQL的执行计划,而没有考虑目标SQL所涉及的对象的实际数据量,实际数据分布等情况,这样一旦固定的规则并不适用于该sql中所涉及的实际对象时,RBO选择的执行计划就不是最优的选择。

执行sql:

select * from emp where mgr = 7902;

假设在表emp的列mgr上事先存在一个名为idx_emp_mgr的单键值B树索引(BTREE),如果我们使用RBO,则不管表EMP的数据量有多大,也不管MGR的数据分布情况如何,它都会始终走索引,对于RBO而言,全表扫描的等级值要高于索引范围扫描的等级值。RBO这种选择在表EMP的数据量不大,或者虽然表emp的数据量很大,但满足mgr=7902的记录很小时是没有问题的,但是当emp表的数据量很大,有1000万条,且1000万条数据都满足mgr=7902,此时RBO还是会选择走索引扫描,因为这相当于单块读顺序扫描所有的1000万行索引,然后在回表1000万次,这显然没有使用多块读以全表扫描方式直接扫描emp的执行效率高。

为了解决RBO的一些缺陷,oracle7开始,引入了CBO,CBO在选择目标SQL的执行计算时,判断原则是成本,CBO会从目标SQL诸多可能的执行路径中选择一条成本最小的执行路径作为其执行计划,各条执行的成本值是根据目标SQL语句涉及的表,索引,列相关对象的统计信息计算出来的。统计信息是这样的一组数据,他们存储在oracle数据库的数据字典里,且从多个维度描述了oracle数据库相关对象的实际量,实际数据分布等详细信息。

8.Cardinality概念

它是指定集合所包含的记录数,其实就是数据查询出来的结果集的行数,他的值越大,对应的成本越高,这个执行路径的总成本值越大。

9.selectvity概念

它是指施加指定谓词条件后返回结果集的记录数占未施加任何谓词条件的原始结果级的记录数的比率。

例子:

执行sql

alter tabel emp_modify(mgr not null)

create index idx_emp_mgr on mgr(mgr)

A=select count(*) from emp ;

 

B=select count(distinct mgr) from emp ;

 从上图可知,selectivity为1/B,则为1/13

 computer Cardinality = original Cardinality * selectivity,即A*selectivity ,为13*1/13=1

执行sql语句:

update emp set mgr = 7902;  

A=select count(*) from emp ;

 

B=select count(distinct mgr) from emp ;

由于将所有的mgr改成了7902,则统计起来会变成1,

此时,计算selectivity为1/B,则为1/1 ===》 1

 computer Cardinality = original Cardinality * selectivity,即A*selectivity ,为13*1=13

 

假设现在有1000万条数据,那么计算的值则变成

computer Cardinality = original Cardinality * selectivity,即A*selectivity ,为1000万*1=1000万

由此可看成本非常大,如果CBO的话,此时就不会走索引,因为这条执行计划成本很大,如果是RBO,由于全表扫描等级会比索引扫描高,此时他还是会走索引扫描,成本大。

10.可传递性

 

Guess you like

Origin www.cnblogs.com/hejj-bk/p/11432450.html