暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

【云和恩墨大讲堂】从执行计划洞察ORACLE优化器的“小聪明”

黄浩 2016-11-28
287
作者简介


黄浩  惠普

十年一剑,十年磨砺。3年通信行业,写就近3万条SQL;5年制造行业,遨游在ETL的浪潮;2年性能优化,厚积薄发自成一家


主题介绍:

Oracle执行计划的另类解读:调皮的执行计划 | 诚实的执行计划 | 朴实的执行计划


说到执行计划,oracle的拥趸们自然而然会兴奋起来。在ORACLE的世界里,执行计划有着其特殊的地位,如果我们将SQL性能优化看成一个生物,那某种程度上,执行计划就是DNA。在某搜索网站中,“oracle 执行计划”关键字的搜索结果与“oracle”关键字的搜索结果占比为1.7%。足可见执行计划在ORACLE中举足轻重的地位:


而当我们输入“oracle执行计划”时,推荐关键字排第一的就是“ORACLE执行计划怎么看”


一个标准的执行计划大致可以分为三个部分:访问方式(表访问、索引访问等)、连接方式(NESTED LOOP、HASH JOIN等)及访问顺序(驱动表等)


我们对上述SQL稍加改动,再看执行计划:


什么情况?DEPT表不见了,执行计划居然“残缺”了:

1、这是ORACLE的BUG吗?

2、少了一张表,结果正确吗?

3、ORACLE优化器如此大胆,其背后是谁在给他撑腰?

4、ORACLE凭什么擅作主张?


为了回答上述问题,我们就进入今天的第一个主题:残缺的执行计划。

残缺的执行计划

在展开之前,我们先做数据准备,分别创建两张表EMP及DEPT,脚本如下:

 

CREATE TABLE DEPT(

        DEPTNO NUMBER(2), 

        DNAME VARCHAR2(14), 

        LOC VARCHAR2(13)); 

 

CREATE TABLE EMP(

        EMPNO NUMBER(4)CONSTRAINT PK_EMP PRIMARYKEY, 

        ENAME VARCHAR2(10), 

        JOB VARCHAR2(9), 

        MGR NUMBER(4), 

        HIREDATE DATE, 

        SAL NUMBER(7,2), 

        COMM NUMBER(7,2), 

        DEPTNO NUMBER(2) ); 

现在我们有如下一条语句:

SELECT COUNT(1)

  FROM EMP E

  LEFTJOIN DEPT D

    ON E.DEPTNO = D.DEPTNO


这条语句非常简单,就是获取EMP表与DEPT表内关联后的数据量。在看具体的执行计划之前,我们解读下在常规情况下,DB是如何处理这样的数据的

1、分别读取emp表和DEPT表的数据;

2、对EMP中的DEPTNO与DEPT表中的DEPTNO进行内关联;

3、对内关联后的数据进行汇总计算;

4、返回汇总计算结果。

也就是说会存在EMP与DEPT表的内关联,因为SQL就是这样写的。那我们看下该语句的执行计划,如下:


ORACLE优化器果真是按照我们的预想制定了执行计划。


1唯一性字段对执行计划的影响

由于在模型分析时,我们发现DEPT表的DEPTNO字段是唯一的。于是我们需要通过如下语句为该字段创建主键:

ALTERTABLE DEPT ADDCONSTRAINT PK_DEPT PRIMARYKEY(DEPTNO);


我们再回过头来看执行计划,会发生变化吗?


如果此时的你还不能看出问题,那么我们就对比下DEPT表的主键创建先后执行计划的变化:


俗话说:不比不知道,一比吓一跳。DEPT莫名其妙的被ORACLE优化器弄“丢”了。这不禁让人怀疑:这样的裁剪是否是不负责任的?也就是说,裁剪后的结果是否会因为裁剪而发生变化?在深入了解到LEFT JOIN的原理及模型结构后,你就会明白为何ORACLE优化器在DEPT表创建了基于DEPTNO字段的主键后,会做这样的裁剪。


支持ORACLE做如此大胆裁剪的理由是:

1、 LEFTJOIN在没有where条件过滤的时候,是不会减少结果数据量的;

2、 如果被关联的字段是被关联表的主键(或者唯一性字段),那么是不会使结果数据量增多的。


既然结果集的数据量不增加也不减少,那为何还要多访问一个表,多做一次关联呢?这就是ORACLE的精明之处:简单的就是高效的。


接下来,我们继续上面的实验(当然是基于上面的模型基础,即在DEPT表上创建了基于DEPTNO字段的主键)。这次,我们将LEFT JOIN改成INNER JOIN,看看执行计划是怎么样的:


表结构和约束关系没有发生变化,消失的DEPT又回来了。

神马原因呢?LEFT JOIN是不会有数据过滤的作用的,但是INNER JOIN则有过滤的功用。

为了验证,我们准备如下数据:

INSERTINTO dept(deptno,dname)VALUES(14,'财务');

INSERTINTO dept(deptno,dname)VALUES(31,'行政');

INSERTINTO EMP(EMPNO, ENAME, DEPTNO)VALUES('001','张三',14);

INSERTINTO EMP(EMPNO, ENAME, DEPTNO)VALUES('002','李四',31);

INSERTINTO EMP(EMPNO, ENAME, DEPTNO)VALUES('003','王五',21);

INSERTINTO EMP(EMPNO, ENAME, DEPTNO)VALUES('004','麻六',14);


现在来看看LEFT JOIN和INNER JOIN的不同结果:



也就是说,LEFT JOIN和INNER JOIN还是有差异的,那么在什么情况下才能在执行计划中将DEPT“枪毙”掉呢?


2主外键约束对执行计划的影响

我们对EMP和DEPT创建一个主外键约束(在创建主外键约束前,我需要删除掉empno=’003’的记录):

ALTERTABLE EMP ADDCONSTRAINT FK_DEPTNO FOREIGNKEY(DEPTNO)REFERENCES DEPT(DEPTNO);


看看效果如何:


这样是不是已经非常明确了DEPT再度消失的原因了?因为创建了主外键,也就是等于说EMP所有的DEPTNO必须要存在DEPT表中,既然有这样的约束,那自然就不需要多此一举的关联DEPT表了。


3字段属性对执行计划的影响

现在我们往EMP表里面再添加一条数据:

INSERTINTO EMP (EMPNO, ENAME, DEPTNO)VALUES('005','赵七',NULL);

再看看INNER JOIN的结果:


结果只有3条数据,明显刚才新增的数据是被过滤掉了,因为他的DEPTNO为null,其null并没有存在于dept表中。

而在执行计划里面,是没有DEPT表的:


也就是说该SQL就应该等价于如下SQL:

SELECT E.EMPNO, E.ENAME

 FROM EMP E

我们再看结果:



不对呀,说好的等价呢?难道是执行计划出了问题?还是我们对执行计划的理解错了?也或许是执行计划对我们隐藏了什么?

以上,我们都是在ORACLE的第三方开发工具PL SQL DEVELOPER里面查看的执行计划。现在我们换种方式,在SQL PLUS里面通过explain plan这种最原始的方式来查看执行计划,如下:


原来,在这个执行计划的内容中,明显的多出了“Predicate Information”,而在这部分信息里面,filter是:E.DEPTNO IS NOT NULL。


好吧,我们先把这个谓词放进SQL中,看看效果:


果然,我们发现,增加了这个谓词后,两个SQL又等价了。此时,我们会想:天哪,如果再遇到其他场景,会不会又不等价了?


在关联条件存在主外键关系约束的前提下,如下两个SQL是等价的:


不管你信不信,反正我信了


而此时,我们来看看EMP.DEPTNO的字段属性:


我们发现其Nullable属性为true,即可为null值。而如果我们将该属性值修改为false呢?

DELETEFROM emp WHERE empno ='005';

COMMIT;

ALTERTABLE EMP MODIFY DEPTNO NOTNULL;

再看执行计划:


我们发现原来的“Predicate Information”不见了,也就没有了E.DEPTNO IS NOT NULL的谓词约束。


4程序员与ORACLE的较量

在上面,我们在极力“宣传”着oracle是多么多么的智能化,而事实上,她的智能程度也是存在局限性的,比如她对SQL语句的取舍绝对的依赖于物理模型结构及约束,而一旦这种物理模型结构及约束不存在,那么ORACLE这位“巧妇”显然也只能“难为无米之炊”了。即便我们在SQL中进行了(唯一性)约束,ORACLE也会选择视而不见,比如如下SQL:

SELECTCOUNT(1)

FROM EMP E

LEFT JOIN (SELECTDISTINCT DEPTNO FROM DEPT) D

ON E.DEPTNO =D.DEPTNO;


按照我们在上面的理解,由于在子查询D中,已经对DEPTNO进行了distinct处理,也就意味着在子查询D中,DEPTNO绝对是唯一性的,即子查询D对整个SQL返回的结果是没有任何影响的,该SQL完全等价于如下SQL:

SELECT COUNT(1) FROM EMP E


而事实上呢,我们看看ORACLE的执行计划:



这一次很让我们意外,ORACLE居然没有识别出子查询D的作用。由此看来,在某些时候,尤其是在错综复杂的业务逻辑面前,oracle往往束手无措,远没有程序员聪明,所以在ORACLE这位巨无霸面前,我们也大可不必妄自菲薄。


5总结


至此,我们可以为第一个主题做出如下总结:

1、ORACLE优化器为达性能之目的,会不择手段的简化Operation;

2、ORACLE优化器的手段之一就是充分利用数据库约束,包括但不局限于:唯一性约束、主外键参照性约束、Nullable约束;

3、在约束条件内,ORACLE会简化SQL,在Operation时不再重复约束;

4、因此,在日常模型设计时,应尽可能的建立约束,最大程度上减少重复约束带来的“非战斗性减员”,从而提升SQL性能


完整的执行计划

在上一节的最后示例中,为了更全面阐述问题,我们“抛弃”了在PL SQL DEVELOPER通过F5得到的执行计划,转而选择了最原始最古老的explain。因为我们发现:


这几列还不足够支撑我们了解ORACLE优化器的意图,或者说还不够让我们拼凑出ORACLE优化器对SQL改写后的全貌。至少我们还需要谓词(Predicate)。所以,一个完整的执行计划除了:访问方式(表访问、索引访问等)、连接方式(NESTED LOOP、HASH JOIN等)及访问顺序外,还应包括谓词(Predicate),通过结合谓词,我们更能还原ORACLE优化器对SQL做了哪些改动?


为了直观期间,我们还是继续在PL SQL DEVELOPER中演示,只是执行计划的正确打开方式是这样的:


那么我们能从谓词中发现什么呢?


我们都知道,在表的统计信息采集及时的场景下,如果某个索引字段存在条件过滤,而执行计划中没有通过索引访问,而是table access full。那么原因无非就是:该过滤条件值的数据量太大(比如超过全表数据量的20%),或者是SQL的写法不当(该字段上应用了函数、表达式等)。


其实,除了上述两种场景外,还有一种场景也会导致table access full。我们先来看一个非常简单的案例,我们在EMP.DEPTNO上创建一个索引,因为经常会遇到查询某个特定部门的员工信息。

CREATEINDEX EMP_I1 ON EMP(DEPTNO);

因为在DEPT表中,DEPTNO的数据类型为NUMBER(2),在查deptno为14的员工信息时,我们会习惯性的写成:

SELECT*FROM emp WHERE deptno =14;


我们的如意算盘是通过索引EMP_I1来访问EMP表。而事实上,从执行计划看,却是table access full的访问方式:



尽管deptno=14的数据量为0,并且也没有在deptno上有任何的函数或者表达式。那么问题出在哪里呢?


我再来看看谓词:


很明显,在实际的执行过程中,DEPTNO是被TO_NUMBER函数包了一层,自然就走不了索引。那么是什么让ORACLE如此“昏庸”,以致“无事生非”的添加一个函数呢?


我们再看看EMP.DEPTNO的数据类型:


原来,EMP.DEPTNO的数据类型并没有同DEPT.DEPTNO保持一致,被设计成了VARCHAR2。因此要想走索引,就有三种办法:将DEPTNO的数据类型修改为NUMBER(2)、创建TO_NUMBER(DEPTNO)的函数索引、将过滤条件有之前的DEPTNO=14修改成DEPTNO=’14’。


我们就看下第三种方案的执行计划:


这才是我们想要的执行计划,却不是我们想要的表模型。这三种方案孰优孰劣不在本次分享主题范围内,如有机会,再行讨论。


没错,这就是隐式强行转换的风险,而所有的字段隐式转换在执行计划中都会被“曝光”

隐式转换都是“无意为之”,有两种场景:其一是对过滤字段的数据类型“想当然”的认为;其二是对过滤值类型的错误判断。刚才的案例属于第一种,那么第二种又是怎么回事呢?


以下是一个真实的案例:

系统中存在一个日志表,数据量非常大,我们对日志表按照日志时间(log_date)做了分区。在页面,要求强制按照log_date过滤,以命中分区而提高效率。但是分区+强制过滤并没有收到预期的性能效果,但是将同样的查询条件直接在DB中执行却非常快。通过对比执行计划发现,通过页面调用执行时,并没有命中分区,而在访问谓词中,log_date字段过滤时,多出了函数INTERNAL_FUNCTION。也就是将log_date字段隐式强制转换成了timestamp。而导致这种问题的原因是JAVA数据类型与ORACLE数据类型之间的转换出现了问题。最后通过JAVA传STRING到ORACLE,然后在SQL中将变量值TO_DATE成DATE类型解决。


我们也可以简单模拟下。比如我们在EMP中创建基于HIREDATE的索引:

CREATEINDEX EMP_I2 ON EMP(HIREDATE);

我们现在要查找今年以来入职的员工信息,SQL如下:

SELECT*FROM EMP WHERE HIREDATE >SYSDATE

其执行计划如下:


而如果我们将date’2016-01-01’转换成timestamp,则执行计划如下:


在这个案例中,如果不查看谓词,就很难找到性能的根源。


朴实的执行计划

我们继续执行计划中的“谓词”,看看还能给我们哪些意外之喜?

在上个章节中,我们注意到,在查询今年入职的员工信息是,我们用了DATE’2016-01-01’。这种写法很少见诸于正式书籍中,因为这是非标准写法。那么将VARCHAR2转换成DATE的标准写法是什么呢?


执行计划会告诉你:



原来DATE’2016-01-01’被转换成了TO_DATE(‘2016-01-01’, ‘SYYYY-MM-DDHH24:MI:SS’),这样是为什么DATE只能支持YYYY-MM-DD格式的字符串的原因:


可见,ORACLE优化器会将SQL中一些非标准的写法转换成标准的朴实的写法。有的时候,最朴实的写法,最容易让人理解。

比如,当你拿到如下SQL时:

SELECT ENAME, SAL

  FROM EMP

 WHERE SAL >SOME(SELECT SAL FROM EMP WHERE DEPTNO =10);

你会不会很懵菜?会不会去查资料,研究SOME的作用和用法?或许大半天后,你仍然被SOME\ANY\ALL弄得云山雾罩的。


现在,我们试着从执行计划去探究>SOME的含义。



我们将子查询替换成具体的LIST(100,200,300),发现在执行计划中,谓词变成了SAL > 100,意思就是大于最小值。换言之,原来的SQL就是要查询大于DEPTNO=10部门最低工资的员工信息。

如何加入"云和恩墨大讲堂"微信群

搜索 盖国强(Eygle) :eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。


近期文章

DRM和read-mostly locking

【SQL执行计划】优化器相关Hint

应用到数据库的连接数管控

Oracle 11g DG环境中的归档管理

一则library cache lock问题处理 

一则强行关库引发的蝴蝶效应

深入学习:In Memory Undo 

资源下载

(OraNews)回复关键字获取

CodeSet,《Oracle性能优化与诊断案例精选》代码;

2016OTC,第六届Oracle技术嘉年华PPT;

2016DTCC, 2016数据库大会PPT;

DBALife,"DBA的一天"精品海报大图;

12cArch,“Oracle 12c体系结构”精品海报;

DBA01,《Oracle DBA手记》第一本下载;

YunHe“云和恩墨大讲堂”案例文档下载;

文章转载自黄浩,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论