oracle性能优化

主题介绍：

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的索引：