码迷,mamicode.com
首页 > 数据库 > 详细

Oracle SQl优化总结

时间:2015-12-04 20:22:09      阅读:281      评论:0      收藏:0      [点我收藏+]

标签:

 

    连续两个公司都作为外派人员到客户方工作,缺少归属感的同时,对数据库技术的热爱是我唯一的安慰,毕竟这是自己喜欢的事情,还可以做下去。

    因为客户项目的需要,我又开始接触Oracle,大部分工作在工作流的优化和业务数据的排查上。为了更好的做这份工作,我有参考过oracle达人,Oracle.10g性能分析与优化思路,基于海量数据的数据库设计与优化等书籍,以及案例学习SQL优化的视频等。基本上我工作中接触的主要是Oracle SQl的优化,基于长时间做SQL优化工作,现在对Oracle的SQL优化做一下自己的总结。

    已知,Oracle10G以后执行计划使用基于CBO: Cost-Based Optimization 基于代价的优化器。当然在oracle 10G运行的SQL执行计划肯定是系统以为的最优了,很多时候没有办法看出优化点,不管怎么改都不比原来的性能好。怎么办呢?我每次还是傻傻的看着执行计划研究半天,很多时候这是不需要的,或者是有更快的方法发现问题所在。

    当然,每个人习惯和优化思路都会有不同,优化问题的处理也会不同。基于最近我优化一个程序的四个修改点,程序有原来的7个小时左右缩短为1小时左右执行。总结下我的步骤和优化思路。

1、直接观察表的数据量和表结构属性,不拘泥考虑执行计划的最优  (大数据表利用全表 Hash关联)

简写原SQL:

SELECT count(1) 
FROM Z_MID_R3_BOM_ORG1 A
WHERE trunc(a.DATUV)<=trunc(sysdate) and trunc(a.DATUB) >=trunc(sysdate)
and exists (select 1 from rpt_fp_shortage_order c
where instr(a.name,c.mtm)>0
and a.werks= c.siteid)
and exists (select 1 from mst_bomcomponentsalt b
where INSTR(b.bomid,a.name)>0
and a.idnrk=b.ALTERNATEITEM
and a.werks=b.siteid);

实际这条SQL的结果集大概在20多万条记录,结果集插入另外一张表。Z_MID_R3_BOM_ORG1表和MST_BOMCOMPONENTSALT 表的数据量在一百多万条记录,RPT_FP_SHORTAGE_ORDER 表的数据量在7000条左右。

执行计划:

SELECT STATEMENT  ALL_ROWSCost: 2,595  Bytes: 64  Cardinality: 1              
    5 FILTER          
        1 TABLE ACCESS FULL TABLE PRDABPPCDB.Z_MID_R3_BOM_ORG1 Cost: 1,198  Bytes: 55,616  Cardinality: 869      
        2 TABLE ACCESS FULL TABLE PRDABPPCDB.RPT_FP_SHORTAGE_ORDER Cost: 3  Bytes: 17  Cardinality: 1      
        4 TABLE ACCESS BY INDEX ROWID TABLE PRDABPPCDB.MST_BOMCOMPONENTSALT Cost: 91  Bytes: 48  Cardinality: 1      
            3 INDEX FAST FULL SCAN INDEX PRDABPPCDB.S9525213703_2688 Cost: 3  Cardinality: 195  
由执行计划可知,PRDABPPCDB.MST_BOMCOMPONENTSALT 表使用快速索引扫描,看似已经是最优。能利用的表属性索引已经使用了。但是近20万条记录,观察日志发现这一步骤插入的时间用了快2个小时。利用全表 Hash关联,修改后插入表的时间约为3分钟内执行完。

修改后的SQL:

SELECT count(1) 
FROM Z_MID_R3_BOM_ORG1 A
WHERE trunc(a.DATUV)<=trunc(sysdate) and trunc(a.DATUB) >=trunc(sysdate)
and exists (select 1 from rpt_fp_shortage_order c 
where instr(a.name,c.mtm)>0
and a.werks= c.siteid)
and exists (select /*+FULL(B)*/ 1 from mst_bomcomponentsalt b
where INSTR(b.bomid,a.name)>0
and a.idnrk=b.ALTERNATEITEM
and a.werks=b.siteid);

修改后的执行计划:
Plan
SELECT STATEMENT  ALL_ROWSCost: 8,748  Bytes: 111  Cardinality: 1                  
    6 SORT AGGREGATE  Bytes: 111  Cardinality: 1              
        5 FILTER          
            3 HASH JOIN SEMI  Cost: 8,676  Bytes: 111  Cardinality: 1      
                1 TABLE ACCESS FULL TABLE PRDABPPCDB.Z_MID_R3_BOM_ORG1 Cost: 2,493  Bytes: 107,280  Cardinality: 1,788  
                2 TABLE ACCESS FULL TABLE PRDABPPCDB.MST_BOMCOMPONENTSALT Cost: 6,172  Bytes: 52,636,539  Cardinality: 1,032,089  
            4 TABLE ACCESS FULL TABLE PRDABPPCDB.RPT_FP_SHORTAGE_ORDER Cost: 72  Bytes: 4,389  Cardinality: 133  

2、拆分SQL,分段执行观察整个SQL语句的block,有针对性优化

此处的优化是在表z_dim_product (数据量20万左右)上建立函数索引,lpad(product,18,‘0‘) 

简写SQL:

SELECT MAX (hier11_code)
FROM z_dim_product
WHERE substr(product,length(product)-9,10) =  b.ITEM  (b 表是另一个关联表)

修改后的SQL: 

SELECT MAX (hier11_code)
FROM z_dim_product
WHERE lpad(product,18,‘0‘) =  lpad(b.ITEM,18,‘0‘) 

3、大表优化充分利用分区和分区的索引

4、从业务角度调整逻辑,改写SQL,这种方法往往是所有优化里效果最明显的。

..........

 

后面3\4 的方法没有再上传SQL,有时间会继续记录个人的优化总结

 

 

 

 

 

 

   

Oracle SQl优化总结

标签:

原文地址:http://www.cnblogs.com/flyingsanddream/p/5019982.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!