听“俊”一席话,胜读十年书。看了这篇由DBA+社群联合发起人丁俊大师(网名:dingjun123)分享的SQL优化大作,其他Oracle SQL优化文章都不必再看了!
SQL优化的本质
SQL优化Road Map
2.1 制定SQL优化目标
2.2 检查执行计划
2.3 检查统计信息
2.4 检查高效访问结构
2.5 检查影响优化器的参数
2.6 SQL语句编写问题
2.7 SQL优化器限制导致的执行计划差
SQL优化案例
SQL执行计划获取
4.1 如何获取准确的执行计划
4.2 看懂执行计划执行顺序
一般来说,SQL优化是让SQL运行得更快,使SQL更快的方式有很多,比如提高索引的使用效率,或者并行查询。可以看到里面的公式:
执行效率或者一般说的执行时间,是和完成一次SQL所需要访问的资源总量(S)成正比以及单位时间内能够访问的资源量(V)成反比,S越大,效率越低,V越大效率越高。 比如通过并行查询,则可以提升单位时间内访问的资源量。
当然,这仅仅是从执行时间上考虑,SQL优化肯定不仅仅是执行时间降低,应该是资源使用与执行时间降低之间寻求一种平衡,否则,盲目并行,可能提升不了效率,反而让系统资源消耗殆尽。
最终来说,SQL优化的本质就是:1、缩短响应时间;2、提升系统吞吐量;3、提升系统负载能力。要使用多种手段,在提升系统吞吐量和增加系统负载能力,提高单个SQL效率之间寻求一种平衡。就是要尽量减少一条SQL需要访问的资源总量,比如走索引更好,那么不要使用全表扫描。
一条SQL的优化路线图如下所示:
具体操作步骤:
2.1 制定SQL优化目标
获取待优化SQL、制定优化目标:从AWR、ASH、ORA工具等主动发现有问题的SQL、用户报告有性能问题DBA介入等,通过对SQL的执行情况进行了解,先初步制定SQL的优化目标。
2.2 检查执行计划
explain工具、sql*plus autotrace、dbms_xplan、10046、10053、awrsqrpt.sql等。 执行计划是我们进行SQL优化的核心内容,无计划,不优化。看执行计划有一些技巧,也有很多方式,各种方式之间是有区别的。
2.3 检查统计信息
ORACLE使用DBMS_STATS包对统计信息进行管理,涉及系统统计信息、表、列、索引、分区等对象的统计信息,统计信息是SQL能够使用正确执行计划的保证。我们知道,ORACLE CBO优化器是利用统计信息来判断正确的执行路径,JOIN方式的,因此,准确的统计信息是产生正确执行计划的首要条件。
可以从这个图看出,一条SQL产生执行计划需要经过哪些步骤,在我看来:1、正确的查询转换;2、准确的统计信息,是产生正确执行计划的重要保证。当然,还有BUG,或优化器限制等也会导致SQL效率低下,无法产生正确的执行计划。
如图所示:
2.4 检查高效访问结构
重要的访问结构,诸如索引、分区等能够快速提高SQL执行效率。表存储的数据本身,如碎片过多、数据倾斜严重、数据存储离散度大,也会影响效率。
2.5 检查影响优化器的参数
optimizer_mode、optimizer_index_cost_adj、optimizer_dynamic sampling、_optimizer_mjc_enabled、_optimizer_cost_based_transformation、hash_join_enable等对SQL执行计划影响较大。比如有时候我们通过禁用_optimizer_mjc_enabled 参数,让执行计划不要使用笛卡尔积来提升效率,因为这个参数开启有很多问题,所以一般生产库都要求禁用。
还有什么能够影响执行计划呢?对,new features,每个版本的new features,引入的目的都是好的,但是实际使用中,可能触发BUG。比如11g的ACS(自适应游标共享)、automatic serial direct path(自动串行直接路径读)、extended statistics、SQL query result cache等。有的新特性会导致问题,所以需要谨慎使用。
比如11g adaptive cursor sharing,自适应游标共享,它的引入是为了解决使用绑定变量与数据倾斜值,要产生多样性执行计划。因为绑定变量是为了共享执行计划,但是数据倾斜了,有的值要求走索引,有的值要求走全表,这样与使用绑定变量就产生了矛盾。以前是通过cursor_sharing=similar这样的设置可以解决,但是有很多BUG,会产生version count过高的问题,或者我们对不同的值(如果值很少),可以写多条SQL来解决,这都不是好的方案,11g acs引入就是为了解决这些问题,让这些东西交给oracle来做。但是事与愿违,以后你们遇到执行计划一会变一下,有快有慢,首先可以检查acs有没有关闭。
alter system set “_optimizer_extended_cursor_sharing_rel”=’NONE';
2.6 SQL语句编写问题
SQL语句结构复杂、使用了不合理的语法,比如UNION代替UNION ALL都可能导致性能低下。 并不是说ORACLE优化器很强大了,我们就可以随便写SQL了,那是不正确的。SQL是一门编程语言,它能够执行的快,是有一些普遍的规则的,遵循这种编程语言特性,简化语句,才能写出好的程序。SQL语句编写出了问题,我们就需要改写,就需要调整业务,改涉及等。
2.7 SQL优化器限制导致的执行计划差
这个很重要,统计信息准确,SQL也不复杂,索引也有。。。都满足,为什么我的SQL还是差,那么得考虑优化器限制因素了。这里说1点常见的执行计划限制,当semi join与or连用的时候(也就是exists(subquery) or ...或者in (subquery) or...,如果执行计划中因为OR导致有FILTER操作符,就得注意了,可能慢的因素就和OR有关。这时候我们得改写SQL,当然改写为UNION或UNION ALL了。
OK,以上全部检查完毕,我的系统还是很差,功能还是很慢,或者已经无法从SQL本身进行调整提升性能了,那咋办?优化设计,这是终极方法。有些东西不优化设计是无法解决的,比如业务高峰期跑了一堆SQL,CPU已经很吃紧,又不给增加,突然上线一个耗资源的业务,其他SQL已无法调整。那只能优化设计,比如有些耗资源的业务可以换时间段执行等。
以上几点,是我们进行优化需要考虑的地方,可以逐步检查。当然,80%到90%的纯SQL性能调整,我们通过建立索引,收集正确统计信息,改写避免优化器限制,已经能够解决了。
看第一个获取待优化的SQL.......如果主动优化,一般从AWR、ASH等里面找到性能差的SQL,然后优化之。
看一个案例,占CPU 72%的SQL来自于同一模块,第一行是存储过程,通过下面绿色框住的SQL与第一行比较,主要通过EXECUTION,基本判断下面的绿色框住的SQL就是那个存储过程中的。也可以和业务确认下,OK,这些SQL的执行频次很高,因为是营销业务,如果要优化,就得搞定这些SQL。
这些SQL,单条SQL的buffer gets也就1000多点,效率还是很高的,但是因为执行的太过于频繁,所以资源消耗极大,因此,得检查下,能不能更优呢?
以第1条SQL:58q183atbusat为例:
SELECT B.ACT_ID,
B.ACT_NAME,
B.TASK_ID,
B.MKT_DICTION,
B.CUST_GROUP_ID,
NVL(B.ATTEST_FLAG, 'N'),
NVL(B.DOUWIN_FLAG, 'N'),
B.CHN_DESC,
NVL(B.SIGN_FLAG, 'N'),
B.MAX_EXECUTE_NUM
FROM (SELECT DISTINCT (ACT_ID)
FROM MK_RULECHN_REL
WHERE CHN_STATUS = '04'
AND CHN_TYPE = :B1) A,
TABLE(CAST(:B2 AS TYPE_MK_ACTIONINFO_TABLE)) B
WHERE A.ACT_ID = B.ACT_ID
SQL其实很简单,一个查询构建的A表,一个TABLE函数构建的B表关联..... 不知道大家对这个TABLE函数熟悉不熟悉?也就是将一个集合转成表,是PL/SQL里的东西
那个collection部分就是TABLE函数,下面的表走了全表扫描:
按步骤检查,发现不了问题,但是知道,可能是因为HASH JOIN导致全表扫描的问题,是否走NESTED LOOPS+INDEX更好,很显然,要检查TABLE函数大概返回多少行。
经过确认,最多也就返回200-300行,最终结果集也是几百行而已。
那么猜测,问题就在于TABLE函数,走了HASH JOIN,上面的执行计划,TABLE函数部分,ROWS为空。
来单独检查一把:返回8168行,返回8000多行,足以导致走HASH JOIN了....而事实,我们至多返回200-300行:
所以每个步骤返回的行,是JOIN方式选择的重要因素,可以谷歌一把,TABLE函数返回8168就是个固定值,block_size=8K的时候就是这么大,可以说,这是ORACLE的一个限制。
只要你用了TABLE函数,就偏向于走HASH JOIN了
http://www.oracle-developer.net/display.php?id=427 有兴趣的可以看这个链接的内容。
解决方式很多了,也就是要走NESTED LOOPS+index, 既然8168很大,那么我们就让优化器知道TABLE函数返回的行少点,才百行左右。
以下些都可以,当然也可以使用hint:use_nl等
CARDINALITY hint (9i+) undocumented;
OPT_ESTIMATE hint (10g+) undocumented;
DYNAMIC_SAMPLING hint (11.1.0.7+);
Extensible Optimiser (10g+).
因为SQL的SELECT部分只访问B,全部来自于TABLE函数,所以改写为子查询就可以了,使用子查询,自然distinct也就没有必要了,因为是semi join(半连接)。
最终改写使用cardinality hint让优化器知道B返回的行只有100行,你给我走NESTED LOOPS+INDEX,然后解决。
原来的sql:
修改后的sql:
效率提升几十倍:
一个占72%的应用,我们提升几十倍后,那对系统性能明显是极好的。最终,在执行次数增加50%的情况下,w4sd08pa主机CPU使用率由原来的高峰期平均47%的使用率降低为23%。
这个问题能够解决有两个方面:
1、猜测并测试优化器的限制(table函数固定返回行8168);2、实际返回的行200-300。两者缺一不可。如果实际返回的行就是几千上万,那么,单纯通过优化SQL,也是无法取得良好效果的。
扫描文末二维码,关注DBA+社群微信公众号(dbaplus),可下载DBA+社群技术沙龙、OOW大会、2015GOPS、DCon2015等技术盛典PPT。
四 SQL执行计划获取
执行计划就是SQL调优的核心,上面的SQL也是通过看到执行计划走HASH JOIN可能有问题出发的。
那么首先要搞定2个问题:
1、如何获取我要的执行计划(准确的计划);
2、怎么看懂并找出执行计划里的问题。
4.1 如何获取准确的执行计划
获取SQL执行计划的方式:
EXPLAIN PLAN
估算
忽略绑定变量
非执行
SQL_TRACE
真实计划,需要用TKPROF工具解析
可以获得绑定变量值
EVENT 10053
真实计划
研究执行计划产生的原因
AUTOTRACE
内部使用EXPLAIN PLAN
DBMS_XPLAN
dbms_xplan.display_cursor
dbms_xplan.display_awr
真实计划
OTHERS
如awrsqrpt、sqlt、pl/sql、sql developer、toad等
大家一般怎么获取执行计划?我一般用的较多的是dbms_xplan.display_cursor,优点很明显:1、获取的是真实执行的计划;2、多种参数。还可以获取绑定变量的值方便验证。
10053是检查优化器行为的,实在搞不懂为什么走那个计划可以看看,用得较少。
10046可以检查一些等待事件的内容,也可以获取绑定变量,一般用得也比较少。
set autotrace traceonly或者explain,他们的执行计划是同一来源,记住,都来自plan_table,是估算的,可能不是真实执行的计划,可能是不准的。
所以,你看得不对劲了,就得质疑它的准确性,autotrace traceonly的好处是可以看到一致性读,物理读,返回行等,这是真实的。因为可以用一致性读,物理读来验证优化效果
其他的,比如awrsqrpt等都可以获取执行计划,不过我很少用,特别是plsq developer这种工具,F5看计划,我几乎是不用的,他也是plan table里的估算计划。如果很长,那无法分析。
建议大家看真实的计划,说一点,我经常通过alter session set statistics_level=all或者gather_plan_statistics hint,然后执行sql,然后通过
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));来看实际执行的信息
好处很明显,能够看到执行计划每步的E-ROWS(估算的行),A-ROWS(真实的行),STARTS,BUFFER GETS,A-TIME(真实的执行时间)等信息。。。我们通过对比估算的与真实的差距,可以判断哪些表统计信息可能有问题,执行计划是不是走错了,省的我们自己根据谓词去计算这步导致返回多少行。
注意一点,如果一SQL执行很长时间,通过上面的方式来看计划,我们是可以终止的,比如执行2小时执行不玩的SQL,一般我没有耐心,最多5分钟,我就终止。终止完,通过display_cursor也是可以看出执行信息的。
比如某个步骤执行100万次,我这条SQL才能执行完,要3小时才可以,我5分钟执行了100次,我终止了SQL我要看的就是一个比例情况,可以通过这个比例来判断,哪个步骤耗的时间最长,哪里大概有问题,然后解决。
优化器很多限制的,比如刚才的TABLE函数固定返回8168,或者算法限制.....很多不准的,如果算法算出来的与真实差别很大,那可能就会导致问题。统计信息有时候也无法收集准确的,比如直方图,就有很多问题,所以12c的直方图多了几种....之前只有等高和等频直方图。
刚才的set statistics_level直接写会输出结果,我们可以让他不输出结果:
1、sql内容放到文件中,前面加上set termout off (这样可以对输出结果不输出)
2、然后display_cursor文件中
用这种东西看执行计划,有时候很方便找出问题,否则我们自己得手动根据每个步骤对应的谓词,自己写SQL去计算真实返回的行,然后再来比较,用这个,ORACLE全帮我们干好了。
4.2 看懂执行计划执行顺序
一般怎么看执行计划呢?
COPY到UE里去。
用光标大法,找到入口,最先执行的,光标定位ID=0的,然后一直缩进向下,如果被挡住了,那么这部分就是入口了。
比如ID=10的继续索引,就被ID=11的挡住了,所以第10步就是入口。
找到入口后,反向光标来,利用平行级别的最上最先执行,最右最先执行原则,来看父操作与子操作的关系,移动光标即可。
比如这里的第13步,我只需要定位光标在PARTITION这个P前面,然后向上移动,立马就知道,它的驱动表是ID=5的VIEW,因为他们是对齐的。
然后看看之间的JOIN关系是不是有问题,返回的行估算等。
执行计划最右最上最先执行规则,有个例外,大家知道不??就是通过以上规则,是不正确的。
(标量子查询)
SELECT a.employee_id,
a.department_id,
(SELECT COUNT(*) FROM emp_b b
WHERE a.department_id=b.department_id
) cnt
FROM emp_a a;
比如这个ID=2的在前面,但是它事实上是被ID=3的驱动的,也就是被emp_a驱动的,这违背了一般的执行计划顺序规则,平时注意点就行了,标量子查询谓词里会出现绑定变量,比如这里的:B1,因为每次带一个值去驱动子查询。
搞清楚执行计划怎么干,那么看执行计划看啥?
1、看JOIN的方式
2、看表的访问方式,走全表,走索引
3、看有没有一些经常影响性能的操作,比如FILTER
4、看cardinality(rows)与真实的差距
不要太过于关注COST,COST是估算的,大不一定就慢,小不一定就快……当然比如COST很小,rows返回的都是很小的,很慢。那么,我们可能得考虑统计信息是不是过旧问题。
统计信息很重要,就说一个例子:
走了索引,COST很小,一切都很完美,但是AWR现实占80%的资源。一般啥情况?单纯从SQL上看,也就是这执行计划估计不对,自己测一下,很慢。也就是COST很小,ROWS很小,走索引,很完美的计划是错误的,那么很显然,基本就是统计信息导致的了。
实际第4步走sendtime索引,应该返回1689393行,但是执行计划估算返回1行,统计信息不准确,再次检查统计信息收集日期是5月前的。
SQL> SELECT COUNT(1) FROM MSP.T_MS_MEDIA_TASK WHERE SENDTIME >=TRUNC(SYSDATE,'dd') AND MONTHDAY = TO_CHAR(SYSDATE,'mmdd') ;
? COUNT(1)
----------
? ?1689393
收集统计信息,for all columns size repeat 保持原有直方图信息
?exec DBMS_STATS.GATHER_TABLE_STATS(ownname=>'MSP',tabname=>'T_MS_MEDIA_TASK',estimate_percent=>10,method_opt=>'for all columns size repeat', no_invalidate=>false,cascade=>true,degree => 10);
返回168万行,但是现有统计信息却让cbo认为是1行,这差别也太大了。
method_opt=>'for all columns size repeat', 这里说下,更新统计信息,最好使用for all columns size repeat...
repeat的好处是啥,比如列有直方图,会给你保留,列没有统计信息会按照for all columns size 1收集。。。其他原来怎么收就怎么收。
你用一个for all columns size 1或size skewonly,或者不写(auto)都可能改变原有统计信息的收集方式,都有可能影响SQL的执行效率。
高效访问结构让SQL更快,这个不说了,主要是建索引。如何建索引也是一个很复杂的问题,说一点,一般复合索引,等值查询条件频率高的,作为前导列较好。因为直接访问可能效率比>,<...等高,后者访问了还需要过滤。
下面看下影响优化器的参数导致的性能问题。
这是10g执行计划,一个视图是UNION ALL做的,全部走索引:
但是11.2.0.4全表扫描了。
10g视图有谓词推荐,也就是查询转换里的一种OJPPD=OLD JOIN PUSH PREDICATE
升级到11.2.0.4,视图里的10张表都变成FULL SCAN。
连接谓词(A.“PAYIO_SN”=“B”.“WRTOFF_SN”)未推入到视图中。
执行时间从0.01s到4s,buffer gets从212到99w。
很显然,我要检查,统计信息没有问题,然后怎么干??看在11g里做优化器降级如何。
在11.2.0.4中使用optimizer_features_enable分别测试10.2.0.4和11.2.0.3均可谓词推入到视图中走索引。那么问题就出现在11.2.0.4了,因为11.2.0.3都是可以的。说明11.2.0.4对视图谓词推入算法有了改变。很多优化器的东西,oracle都有参数控制的,除了参数,还有各补对应的fix control。那么先检查补丁相关的
from v$system_fix_control WHERE sql_feature LIKE ‘%JPPD%’
查到了,各种开启关闭,没有用。最后看10053,分析10053,详细参看是否是BUG导致,还是优化器改进问题,参数设置问题:
10053看到默认参数被关了,检查下,大概和查询转换的两个参数:
_optimizer_cost_based_transformation
_optimizer_squ_bottomup
都被关了,当然10.2.0.4和11.2.0.3被关了也是可以的。
还看到基于CBO的查询转换失败,因为参数被关了,OJPPD(10g那种方式)失效了……那当然走不了,JPPD是11g的,也失效了。
基本知道执行计划如何看,关注哪些就很有用了,不要太关注啥COST前面讲了11.2.0.3都可以,到11.2.0.4不行了,那可能有2种原因:1、算法改了;2、BUG。
当然基于正常的理解,视图谓词推荐,ORACLE是必须支持的,也是不存在问题的,所以肯定有正规的解决方式。先看第2个 BUG,按理说,这种常见的东西,特别是这SQL不算复杂,ORACLE应该不会触发BUG,当然,查询转换是存在各种BUG的,11.2.0,4少了很多MOS中搜一下,比如这个JPPD,就有很多BUG,但是没有看到11.2.0.4对应的。
**************************
Predicate Move-Around (PM)
**************************
。。。
OJPPD: OJPPD bypassed: View semijoined to table.
JPPD: JPPD bypassed: View not on right-side of outer-join.
通过这个判断,10.2.0.4那种OJPPD,基于规则的查询转换不行了,也就是算法改变,因为cost_base_query_transformation参数关了,应该走OJPPD的。现在JPPD也走不了,因为参数被关了,这个是基于成本的查询转换才可以。
所以,这是由于算法更新导致的问题,要求必须按照ORACLE官方建议,恢复对应查询转换参数默认值:在基于COST的查询转换部分,只能走JPPD(和OJPPD类似),ORACLE建议设置CBQT参数,基于COST查询转换更准确。
开启COST查询转换,初始化优化器参数 _optimizer_cost_based_transformation设为默认值(linear)。CBQT参数有如下值:
"exhaustive", "iterative", "linear", "on", "off"。
另外通过测试得知,还需要设置_optimizer_squ_bottomup (enables unnesting of subquery in a bottom-up manner)
参数默认值true.
这个问题,但是发了SR,老外也不知道,然后我发现这2个参数恢复默认值可以,当然首先cbqt参数我认为肯定有关系,后面的squ_bottomup是测试出来的。。。后来告诉老外,老外也认可算法改变导致的问题。所以核心参数的默认值改变,是很危险的,可能影响全局,如果这两个参数不恢复,涉及数百条核心SQL就无法正常执行,也就是系统不具有可用性了。
最后说一下,经常碰到的一个优化器缺陷:
SELECT ELEMENT_TYPEA,
ELEMENT_IDA,
ELEMENT_TYPEB,
ELEMENT_IDB,
RELATION_TYPE,
EFF_RULE_ID,
EXP_RULE_ID,
CTRL_CODE,
EFF_DATE,
EXP_DATE,
GROUP_ID,
BASE_TIME_ TYPE,
POWER_RIGHT,
POSITIVE_TYPE,
BOTHWAY_FLAG
FROM DBPRODADM.pd_prc_rel a
WHERE EXISTS (SELECT 1
FROM DBPRODADM.pd_prc_dict b
WHERE a.element_ida = b.prod_prcid
AND b.prod_prc_type = '1')
AND a.exp_date > SYSDATE
AND (EXISTS (SELECT 1
FROM DBPRODADM.pd_prc_dict c
WHERE a.element_idb = c.prod_prcid
AND c.prod_prc_type = '1')
OR a.element_idb = 'X')
AND a.relation_type = '10'
当OR与semi join放在一起的时候,会触发无法进行subquery unnest的问题,也就是可能会产生FILTER,导致SQL非常缓慢,有的甚至几天,几十天也别想运行结束了。
第5、6步执行92万多次,那肯定慢了……问题就是有个FILTER……
FILTER类似循环,在无法unnest子查询中存在,类似标量子查询那种走法,谓词里也有绑定变量的东西。
他们唯一的好处就是内部构建HASH 表,如果匹配的重复值特别多,那么探测次数少,效率好,但是大部分时候,重复值不多,那么就是灾难了
对于这种优化器限制的,一般就是得改写了,因为SQL结构决定无法走高效的执行计划。。。因为我这里虽然走了所以,但是执行次数太多,如果执行次数少,到也无所谓。
改写后的sql:
SELECT ELEMENT_TYPEA,
ELEMENT_IDA,
ELEMENT_TYPEB,
ELEMENT_IDB,
RELATION_TYPE,
EFF_RULE_ID,
EXP_RULE_ID,
CTRL_CODE,
EFF_DATE,
EXP_DATE,
GROUP_ID,
BASE_TIME_ TYPE,
POWER_RIGHT,
POSITIVE_TYPE,
BOTHWAY_FLAG
FROM DBPRODADM.pd_prc_rel a
WHERE EXISTS (SELECT 1
FROM DBPRODADM.pd_prc_dict b
WHERE a.element_ida = b.prod_prcid
AND b.prod_prc_type = '1')
AND a.exp_date > SYSDATE
AND (EXISTS (SELECT 1
FROM DBPRODADM.pd_prc_dict c
WHERE a.element_idb = c.prod_prcid
AND c.prod_prc_type = '1')
OR a.element_idb = 'X')
AND a.relation_type = '10'
很显然,这里的条件是exists or ...那么改写得用UNION或UNION ALL了,为了避免有重复行,用UNION
select ELEMENT_TYPEA,ELEMENT_IDA,ELEMENT_TYPEB,ELEMENT_IDB,RELATION_TYPE
,EFF_RULE_ID,EXP_RULE_ID,CTRL_CODE,EFF_DATE,EXP_DATE,GROUP_ID,BASE_TIME_TYPE,
POWER_RIGHT,POSITIVE_TYPE,BOTHWAY_FLAG
from DBPRODADM.pd_prc_rel a
where exists
(select 1
from DBPRODADM.pd_prc_dict b
where a.element_ida = b.prod_prcid
and b.prod_prc_type = '1')
and a.exp_date > sysdate
and exists (select 1
from DBPRODADM.pd_prc_dict c
where a.element_idb = c.prod_prcid
and c.prod_prc_type = '1')
and a.relation_type = '10'
union
select ELEMENT_TYPEA,ELEMENT_IDA,ELEMENT_TYPEB,ELEMENT_IDB,RELATION_TYPE
,EFF_RULE_ID,EXP_RULE_ID,CTRL_CODE,EFF_DATE,EXP_DATE,GROUP_ID,BASE_TIME_TYPE,
POWER_RIGHT,POSITIVE_TYPE,BOTHWAY_FLAG
from DBPRODADM.pd_prc_rel a
where exists
(select 1
from DBPRODADM.pd_prc_dict b
where a.element_ida = b.prod_prcid
and b.prod_prc_type = '1')
and a.exp_date > sysdate
and a.element_idb = 'X'
and a.relation_type = '10';
两个分支都走HASH JOIN,starts全部为1,虽然全部是全表扫描,但是执行效率提升很明显,执行时间从12s到7s,gets从222w到4.5w之后,是否还有优化空间?
特别逻辑读少了很多。后续优化:
1)改写使用了UNION,是否能改成UNION ALL避免排序?
2)这么多全表扫描,是否能够让一些可以走索引?当然,这些是可以做到的,但是不是主要工作了。这个案例告诉我们,优化器是有很多限制的,不是万能的。
除了统计信息正确,良好的SQL结构,能够让SQL正确进行查询转换,正确的访问结构,如索引等……都是让SQL高效执行的前提条件。复杂!=低效,简单!=高效。让优化器理解,并且有合适的访问结构支持,才是王道!
简单的SQL不是快的保证,复杂的也不一定见得慢,高效的执行计划才是最重要的,索引优化SQL,最重要的就是让不好的执行计划变得好。
也就是从多个方面入手,最终达到我们的优化目标。