专题第一篇《Oracle之SQL优化专题01-查看SQL执行计划的方法》讲到了查看SQL执行计划的方法,并介绍了各种方法的应用场景,那么这一篇就主要介绍下如何看懂SQL的执行计划。毕竟如果SQL的执行计划都看不懂,那优化就无从谈起了。

关于如何看懂SQL的执行计划,我把它简单分为3个部分:

1.判断执行计划的执行顺序

**口诀:**先子后父,先上后下。
一般简单的执行计划可以直接根据这个口诀来判断执行计划的执行顺序。类似的口诀还有"最右最上"之类,其表达的意思都是一样的,选择一种自己易接受的口诀记忆即可。
举一个简单的例子:

  1. SQL> show user
  2. USER is "SYS"
  3. SQL> alter session set current_schema=scott;
  4. SQL> alter session set statistics_level = ALL;
  5. SQL> select a.empno, a.ename, b.dname, a.job, a.sal from emp a, dept b
  6. 2 where a.deptno = b.deptno and empno = 7788
  7. 3 ;
  8. EMPNO ENAME DNAME JOB SAL
  9. ---------- ---------- -------------- --------- ----------
  10. 7788 SCOTT RESEARCH ANALYST 3000
  11. SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
  12. PLAN_TABLE_OUTPUT
  13. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  14. SQL_ID 19ktq5t44xsyp, child number 0
  15. -------------------------------------
  16. select a.empno, a.ename, b.dname, a.job, a.sal from emp a, dept b where
  17. a.deptno = b.deptno and empno = 7788
  18. Plan hash value: 2385808155
  19. --------------------------------------------------------------------------------------------------
  20. | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
  21. --------------------------------------------------------------------------------------------------
  22. | 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 4 |
  23. | 1 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 4 |
  24. | 2 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 1 | 1 |00:00:00.01 | 2 |
  25. |* 3 | INDEX UNIQUE SCAN | PK_EMP | 1 | 1 | 1 |00:00:00.01 | 1 |
  26. | 4 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 1 | 1 |00:00:00.01 | 2 |
  27. |* 5 | INDEX UNIQUE SCAN | PK_DEPT | 1 | 1 | 1 |00:00:00.01 | 1 |
  28. --------------------------------------------------------------------------------------------------
  29. Predicate Information (identified by operation id):
  30. ---------------------------------------------------
  31. 3 - access("EMPNO"=7788)
  32. 5 - access("A"."DEPTNO"="B"."DEPTNO")
  33. 24 rows selected.

执行计划的执行顺序(按Id区分)就是 3 -> 2 -> 5 -> 4 -> 1 -> 0.

这里需要特别注意的是:

1)实际上这个所谓的口诀得到的执行顺序只是为了方便我们理解操作数据的顺序,而执行计划其实是按照Id从上往下递归调用的,简单说其实优化器首先判断是一条select语句,涉及多表关联,关联方式采用了NL Join,然后这个NL Join包含分别对EMP和DEPT索引回表的访问。

2)理解了第一点,那对于SQL语句中select部分含有标量子查询的部分不遵循这个口诀就更好理解了(因为实际这个标量子查询是最后执行的)。

举一个简单例子说明这类标量子查询:

  1. SQL> select a.empno, a.ename, b.dname, a.job, a.sal, (select * from dual) x from emp a, dept b
  2. 2 where a.deptno = b.deptno and empno = 7788
  3. 3 ;
  4. EMPNO ENAME DNAME JOB SAL X
  5. ---------- ---------- -------------- --------- ---------- -
  6. 7788 SCOTT RESEARCH ANALYST 3000 X
  7. SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
  8. PLAN_TABLE_OUTPUT
  9. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  10. SQL_ID dpbagkc0c6ctv, child number 0
  11. -------------------------------------
  12. select a.empno, a.ename, b.dname, a.job, a.sal, (select * from dual) x
  13. from emp a, dept b where a.deptno = b.deptno and empno = 7788
  14. Plan hash value: 1121436124
  15. --------------------------------------------------------------------------------------------------
  16. | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
  17. --------------------------------------------------------------------------------------------------
  18. | 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 4 |
  19. | 1 | TABLE ACCESS FULL | DUAL | 1 | 1 | 1 |00:00:00.01 | 2 |
  20. | 2 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 4 |
  21. | 3 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 1 | 1 |00:00:00.01 | 2 |
  22. |* 4 | INDEX UNIQUE SCAN | PK_EMP | 1 | 1 | 1 |00:00:00.01 | 1 |
  23. | 5 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 1 | 1 |00:00:00.01 | 2 |
  24. |* 6 | INDEX UNIQUE SCAN | PK_DEPT | 1 | 1 | 1 |00:00:00.01 | 1 |
  25. --------------------------------------------------------------------------------------------------
  26. Predicate Information (identified by operation id):
  27. ---------------------------------------------------
  28. 4 - access("EMPNO"=7788)
  29. 6 - access("A"."DEPTNO"="B"."DEPTNO")
  30. 25 rows selected.

执行计划的执行顺序(按Id区分),如果按口诀来看就是 1 -> 4 -> 3 -> 6 -> 5 -> 2 -> 0.

而由于这其中1是标量子查询,实际要最后执行,所以真实的执行顺序为 4 -> 3 -> 6 -> 5 -> 2 -> 1 -> 0.

2.理解执行计划每步的含义

以上面的执行计划为例,要清楚知道每一列代表的含义:
- Id
操作id号;

  • Operation

    这一列,可以看到SQL的每一步操作,深入理解就需要清楚表的主要访问方式(TABLE ACCESS FULL、TABLE ACCESS BY INDEX ROWID、TABLE ACCESS BY USER ROWID),索引的主要访问方式(INDEX UNIQUE SCAN、INDEX RANGE SCAN、INDEX FULL SCAN、INDEX FAST FULL SCAN、INDEX SKIP SCAN),多表查询还需要清楚表连接的方法(NESTED LOOP JOIN、SORT MERGE JOIN、HASH JOIN、MERGE JOIN CARTESIAN)和顺序(先访问驱动表)等知识;

  • Name

    这一列,就是操作的具体对象名称;

  • Starts

    这一列,代表访问次数;比如在NESTED LOOP JOIN中,被驱动表的具体访问次数就可以依据Starts的数值来判断。

  • E-Rows

    预估返回行数;

  • A-Rows

    实际返回行数;

  • A-Time

    实际执行时间;

  • Buffers

    逻辑读块/次;

如果是其他方式,看到的执行计划内容有所不同,比如可能就是下面这样:

  1. Execution Plan
  2. ----------------------------------------------------------
  3. Plan hash value: 1121436124
  4. ----------------------------------------------------------------------------------------
  5. | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
  6. ----------------------------------------------------------------------------------------
  7. | 0 | SELECT STATEMENT | | 1 | 38 | 2 (0)| 00:00:01 |
  8. | 1 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
  9. | 2 | NESTED LOOPS | | 1 | 38 | 2 (0)| 00:00:01 |
  10. | 3 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 25 | 1 (0)| 00:00:01 |
  11. |* 4 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 0 (0)| 00:00:01 |
  12. | 5 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 | 13 | 1 (0)| 00:00:01 |
  13. |* 6 | INDEX UNIQUE SCAN | PK_DEPT | 1 | | 0 (0)| 00:00:01 |
  14. ----------------------------------------------------------------------------------------

可以看到,前三列没有区别,后面只有Rows、Bytes、Cost (%CPU)、Time等信息。

3.了解执行计划相关的信息

执行计划下面还有相关的信息,类似如下:

  1. Predicate Information (identified by operation id):
  2. ---------------------------------------------------
  3. 4 - access("EMPNO"=7788)
  4. 6 - access("A"."DEPTNO"="B"."DEPTNO")
  5. Note
  6. -----
  7. - SQL plan baseline SQL_PLAN_9sdj6nc4ybu5x2b78d17a used for this statement
  8. Statistics
  9. ----------------------------------------------------------
  10. 0 recursive calls
  11. 0 db block gets
  12. 6 consistent gets
  13. 0 physical reads
  14. 0 redo size
  15. 879 bytes sent via SQL*Net to client
  16. 520 bytes received via SQL*Net from client
  17. 2 SQL*Net roundtrips to/from client
  18. 0 sorts (memory)
  19. 0 sorts (disk)
  20. 1 rows processed
  • 谓词信息(Predicate Information)

    标识出哪一步有access、filter这样的操作;

  • Note部分(Note)

    如果SQL执行中用到了动态采样、基数反馈、自适应游标共享、SQL_Profile、SPM等,会在这里显示出来;

  • 统计信息(Statistics)

    这里指的是SQL执行实际发生的递归调用、逻辑读、物理读、排序、处理行数等统计信息。

Oracle之SQL优化专题03-如何看懂SQL的执行计划的更多相关文章

  1. Oracle之SQL优化专题01-查看SQL执行计划的方法

    在我2014年总结的"SQL Tuning 基础概述"中,其实已经介绍了一些查看SQL执行计划的方法,但是不够系统和全面,所以本次SQL优化专题,就首先要系统的介绍一下查看SQL执 ...

  2. 【重磅干货】看了此文,Oracle SQL优化文章不必再看!

    目录 SQL优化的本质 SQL优化Road Map 2.1 制定SQL优化目标 2.2 检查执行计划 2.3 检查统计信息 2.4 检查高效访问结构 2.5 检查影响优化器的参数 2.6 SQL语句编 ...

  3. 梁敬彬老师的《收获,不止SQL优化》,关于如何缩短SQL调优时间,给出了三个步骤,

    梁敬彬老师的<收获,不止SQL优化>,关于如何缩短SQL调优时间,给出了三个步骤, 1. 先获取有助调优的数据库整体信息 2. 快速获取SQL运行台前信息 3. 快速获取SQL关联幕后信息 ...

  4. SQL Server中参数化SQL写法遇到parameter sniff ,导致不合理执行计划重用的一种解决方案

    parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的 ...

  5. Oracle之SQL优化专题02-稳固SQL执行计划的方法

    首先构建一个简单的测试用例来实际演示: create table emp as select * from scott.emp; create table dept as select * from ...

  6. 数据库sql优化总结之5--数据库SQL优化大总结

    数据库SQL优化大总结 小编最近几天一直未出新技术点,是因为小编在忙着总结整理数据库的一些优化方案,特此奉上,优化总结较多,建议分段去消化,一口吃不成pang(胖)纸 一.百万级数据库优化方案 1.对 ...

  7. 学习如何看懂SQL Server执行计划(三)——连接查询篇

    三.连接查询部分 --------------------嵌套循环-------------------- /* UserInfo表数据少.Coupon表数据多嵌套循环可以理解为就是两层For循环,外 ...

  8. 学习如何看懂SQL Server执行计划(二)——函数计算篇

    二.函数计算部分 --------------------标量聚合--------------------/* 标量聚合-主要在聚合函数操作中产生 计算标量:根据行中的现有值计算出一个新值 流聚合:在 ...

  9. 学习如何看懂SQL Server执行计划(一)——数据查询篇

    一.数据查询部分 1. 看到执行计划有两种方式,对sql语句按Ctrl+L,或按Ctrl+M打开显示执行计划窗口每次执行sql都会显示出相应的执行计划 2. 执行计划的图表是从右向左看的 3. SQL ...

随机推荐

  1. Golang 如何交叉编译

    Golang 支持交叉编译,即在一个平台上生成另一个平台的可执行程序.方法如下: Mac 下编译 Linux 和 Windows 64位可执行程序 CGO_ENABLED=0 GOOS=linux G ...

  2. js读取本地json/txt/xml存在跨越问题,可以用jsonp 读取本地json文件

    想自己用 js写一个原生的ajax请求,访问本地文件,json/txt.但是demo,写了一个后,发现 原来是跨域了. js 写的原生ajax 请求代码如下 html代码 <div id=&qu ...

  3. C语言结构体指针(指向结构体的指针)详解

    C语言结构体指针详解 一.前言 一个指向结构体的变量的指针表示的是这个结构体变量占内存中的起始位置,同样它也可以指向结构体变量数组. *a).b 等价于 a->b. "."一 ...

  4. 二十 Spring的事务管理及其API&事务的传播行为,编程式&声明式(xml式&注解式,底层AOP),转账案例

    Spring提供两种事务方式:编程式和声明式(重点) 前者需要手写代码,后者通过配置实现. 事务的回顾: 事务:逻辑上的一组操作,组成这组事务的各个单元,要么全部成功,要么全部失败 事务的特性:ACI ...

  5. Vue - 路由守卫使用

    import Vue from 'vue' import VueRouter from 'vue-router' import Home from '../views/Home.vue' Vue.us ...

  6. AJAX的兼容处理方式

    AJAX在网站服务中使用到频率很高,也需要考虑各个浏览器版本的兼容性,本示例中详细介绍简单快捷的处理兼容性问题. <!DOCTYPE HTML> <html> <head ...

  7. ROS-5 : 自定义消息

    自定义消息一般存储在功能包的msg文件夹下的.msg文件中,这些定义可告诉ROS这些数据的类型和名称,以便于在ROS 节点中使用.添加完这些自定义消息后,ROS会将其转为等效的C++节点,从而可在其他 ...

  8. redis.rpm 安装

    yum install jemalloc wget http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/redis-3.0.7 ...

  9. python-python基础5(模块)

    一.模块介绍 定义:本质上就是.py结尾的python文件.模块,用一砣代码实现了某个功能的代码集合. 类似于函数式编程和面向过程编程,函数式编程则完成一个功能,其他代码用来调用即可,提供了代码的重用 ...

  10. 第1节 IMPALA:4、5、linux磁盘的挂载和上传压缩包并解压

    第二步:开机之后进行磁盘挂载 分区,格式化,挂载新磁盘 磁盘挂载 df -lh fdisk -l 开始分区 fdisk /dev/sdb   这个命令执行后依次输 n  p  1  回车  回车  w ...