Oracle获取执行计划的6中方式，以及每种方式的优缺点

最新推荐文章于 2023-07-19 18:09:56 发布
原创 最新推荐文章于 2023-07-19 18:09:56 发布 · 848 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍六种获取SQL执行计划的方法，并分析各种方法的适用场景及优缺点。包括使用EXPLAIN PLAN FOR、AUTOTRACE、STATISTICS_LEVEL设置、SQL_ID直接获取、10046 TRACE跟踪及AWR报告。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 /*
  总的结论：
  
  一.获取执行计划的6种方法(详细步骤已经在每个例子的开头注释部分说明了）：
    1. explain plan for获取； 
    2. set autotrace on ；    
    3. statistics_level=all;
    4. 通过dbms_xplan.display_cursor输入sql_id参数直接获取
    5. 10046 trace跟踪
    6. awrsqrpt.sql
    
  二.适用场合分析
  
    1.如果某SQL执行非常长时间才会出结果，甚至慢到返回不了结果，这时候看执行计划就只能用方法1；
    2.跟踪某条SQL最简单的方法是方法1，其次就是方法2；
    3.如果想观察到某条SQL有多条执行计划的情况，只能用方法4和方法6；
    4.如果SQL中含有多函数，函数中套有SQL等多层递归调用，想准确分析，只能使用方法5；
    5.要想确保看到真实的执行计划，不能用方法1和方法2；
    6.要想获取表被访问的次数，只能使用方法3； 
   
*/


/*


分结论1（表访问次数）：


一. 本次脚本重点是教会大家各个获取执行计划的方法和区别。
二. 执行计划中"表访问次数” 是关键指标，这只能靠方法3的方式获取。
   隆重推出本次明星：方法3的statistics_level=all;


*/


--环境构造
--研究Nested Loops Join访问次数前准备工作
DROP TABLE t1 CASCADE CONSTRAINTS PURGE; 
DROP TABLE t2 CASCADE CONSTRAINTS PURGE; 
CREATE TABLE t1 (
     id NUMBER NOT NULL,
     n NUMBER,
     contents VARCHAR2(4000)
   )
   ; 
CREATE TABLE t2 (
     id NUMBER NOT NULL,
     t1_id NUMBER NOT NULL,
     n NUMBER,
     contents VARCHAR2(4000)
   )
   ; 
execute dbms_random.seed(0); 
INSERT INTO t1
     SELECT  rownum,  rownum, dbms_random.string('a', 50)
       FROM dual
     CONNECT BY level <= 1000
      ORDER BY dbms_random.random; 
INSERT INTO t2 SELECT rownum, rownum, rownum, dbms_random.string('b', 50) FROM dual CONNECT BY level <= 100000
    ORDER BY dbms_random.random; 
COMMIT; 
CREATE INDEX t1_n ON t1 (n);
CREATE INDEX t2_t1_id ON t2(t1_id);
/*
  下面我们将会用多种方法来查看如下语句的执行计划
SELECT  *
FROM t1, t2
WHERE t1.id = t2.t1_id
AND t1.n in(18,19);


*/


----方法1(explain plan for 的方式。类似PLSQL DEVELOPE里的F5)


/*
  步骤1：explain plan for "你的SQL"
  步骤2：select * from table(dbms_xplan.display()); 
*/


set linesize 1000
set pagesize 2000
explain plan for
SELECT  *
FROM t1, t2
WHERE t1.id = t2.t1_id
AND t1.n in(18,19);
select * from table(dbms_xplan.display());


PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------
Plan hash value: 3532430033
-------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |     2 |  8138 |     6   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                  |          |       |       |            |          |
|   2 |   NESTED LOOPS                 |          |     2 |  8138 |     6   (0)| 00:00:01 |
|   3 |    INLIST ITERATOR             |          |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID| T1       |     2 |  4056 |     2   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | T1_N     |     1 |       |     1   (0)| 00:00:01 |
|*  6 |    INDEX RANGE SCAN            | T2_T1_ID |     1 |       |     1   (0)| 00:00:01 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | T2       |     1 |  2041 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   5 - access("T1"."N"=18 OR "T1"."N"=19)
   6 - access("T1"."ID"="T2"."T1_ID")
Note
-----
   - dynamic sampling used for this statement (level=2)


已选择24行。
/*
优点：  1.无需真正执行，快捷方便


缺陷：  1.没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；
        2.无法判断是处理了多少行；
        3.无法判断表被访问了多少次。
        
确实啊，这毕竟都没有真正执行又如何得知真实运行产生的统计信息。
*/




----方法2(set autotrace on 方式)
/*
  步骤1：set autotrace on 
  步骤2：在此处执行你的SQL即可，后续自然会有结果输出
  
另，有如下几种方式：
                     set autotrace on                 (得到执行计划，输出运行结果）
                     set autotrace traceonly          (得到执行计划，不输出运行结果）
                     set autotrace traceonly explain  (得到执行计划，不输出运行结果和统计信息部分，仅展现执行计划部分）
                     set autotrace traceonl statistics(不输出运行结果和执行计划部分，仅展现统计信息部分）
*/
set autotrace on 
SELECT  *
FROM t1, t2
WHERE t1.id = t2.t1_id
AND t1.n in(18,19);


执行计划
----------------------------------------------------------
Plan hash value: 3532430033
-------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |     2 |  8138 |     6   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                  |          |       |       |            |          |
|   2 |   NESTED LOOPS                 |          |     2 |  8138 |     6   (0)| 00:00:01 |
|   3 |    INLIST ITERATOR             |          |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID| T1       |     2 |  4056 |     2   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | T1_N     |     1 |       |     1   (0)| 00:00:01 |
|*  6 |    INDEX RANGE SCAN            | T2_T1_ID |     1 |       |     1   (0)| 00:00:01 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | T2       |     1 |  2041 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   5 - access("T1"."N"=18 OR "T1"."N"=19)
   6 - access("T1"."ID"="T2"."T1_ID")
Note
-----
   - dynamic sampling used for this statement (level=2)
统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         12  consistent gets
          0  physical reads
          0  redo size
       1032  bytes sent via SQL*Net to client
        416  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          2  rows processed


/*
--优点：1.可以输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；
        2.虽然必须要等语句执行完毕后才可以输出执行计划，但是可以有traceonly开关来控制返回结果不打屏输出。
                  
--缺陷：1.必须要等到语句真正执行完毕后，才可以出结果；
        2.无法看到表被访问了多少次。        
         
*/         
         
         
----方法3（statistics level=all的方式)  
/*
  步骤1：alter session set statistics_level=all ;
  步骤2：在此处执行你的SQL
  步骤3：select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
  
 另注：
 
  1. 如果你用 /*+ gather_plan_statistics */的方法，可以省略步骤1，直接步骤2,3。
  2. 关键字解读（其中OMem、1Mem和User-Mem在后续的课程中会陆续见到）： 
    Starts为该sql执行的次数。
    E-Rows为执行计划预计的行数。
    A-Rows为实际返回的行数。A-Rows跟E-Rows做比较，就可以确定哪一步执行计划出了问题。
    A-Time为每一步实际执行的时间（HH：MM：SS.FF），根据这一行可以知道该sql耗时在了哪个地方。
    Buffers为每一步实际执行的逻辑读或一致性读。
    Reads为物理读。
    OMem:当前操作完成所有内存工作区(Work Aera)操作所总共使用私有内存(PGA)中工作区的大小，
         这个数据是由优化器统计数据以及前一次执行的性能数据估算得出的
    1Mem:当工作区大小无法满足操作所需的大小时，需要将部分数据写入临时磁盘空间中(如果仅需要写入一次就可以完成操作，
         就称一次通过，One-Pass;否则为多次通过，Multi_Pass).该列数据为语句最后一次执行中，单次写磁盘所需要的内存
         大小，这个由优化器统计数据以及前一次执行的性能数据估算得出的
    User-Mem:语句最后一次执行中，当前操作所使用的内存工作区大小，括号里面为(发生磁盘交换的次数,1次即为One-Pass,
           大于1次则为Multi_Pass,如果没有使用磁盘，则显示OPTIMAL)
    OMem、1Mem为执行所需的内存评估值，0Mem为最优执行模式所需内存的评估值，1Mem为one-pass模式所需内存的评估值。
    0/1/M 为最优/one-pass/multipass执行的次数。Used-Mem耗的内存
  
*/       
set autotrace off          
alter session set statistics_level=all ;
SELECT  *
FROM t1, t2
WHERE t1.id = t2.t1_id
AND t1.n in(18,19);
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));


PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------
SQL_ID  1a914ws3ggfsn, child number 0
-------------------------------------
SELECT  * FROM t1, t2 WHERE t1.id = t2.t1_id AND t1.n in(18,19)


Plan hash value: 3532430033
-----------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |      1 |        |      2 |00:00:00.01 |      12 |
|   1 |  NESTED LOOPS                  |          |      1 |        |      2 |00:00:00.01 |      12 |
|   2 |   NESTED LOOPS                 |          |      1 |      2 |      2 |00:00:00.01 |      10 |
|   3 |    INLIST ITERATOR             |          |      1 |        |      2 |00:00:00.01 |       5 |
|   4 |     TABLE ACCESS BY INDEX ROWID| T1       |      2 |      2 |      2 |00:00:00.01 |       5 |
|*  5 |      INDEX RANGE SCAN          | T1_N     |      2 |      1 |      2 |00:00:00.01 |       3 |
|*  6 |    INDEX RANGE SCAN            | T2_T1_ID |      2 |      1 |      2 |00:00:00.01 |       5 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | T2       |      2 |      1 |      2 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   5 - access(("T1"."N"=18 OR "T1"."N"=19))
   6 - access("T1"."ID"="T2"."T1_ID")
Note
-----
   - dynamic sampling used for this statement (level=2)


已选择29行。
/*
--优点：1.可以清晰的从STARTS得出表被访问多少。
        2.可以清晰的从E-ROWS和A-ROWS中得到预测的行数和真实的行数，从而可以准确判断Oracle评估是否准确。
        3.虽然没有专门的输出运行时的相关统计信息，但是执行计划中的BUFFERS就是真实的逻辑读的多少
                 
--缺陷：1.必须要等到语句真正执行完毕后，才可以出结果。
        2.无法控制记录输屏打出，不像autotrace有 traceonly 可以控制不将结果打屏输出。
        3.看不出递归调用的次数，看不出物理读的多少（不过逻辑读才是重点）
*/






----方法4(知道sql_id后，直接带入的方式，简单，就步骤1）


  
/*  


步骤1： select  * from table(dbms_xplan.display_cursor('&sq_id')); （该方法是从共享池里得到）


注：
  1. 还有一个方法，select  * from table(dbms_xplan.display_awr('&sq_id'));（这是awr性能视图里获取到的）
  2. 如果有多执行计划，可以用类似方法查出
    select * from table(dbms_xplan.display_cursor('cyzznbykb509s',0));
    select * from table(dbms_xplan.display_cursor('cyzznbykb509s',1));


*/




select * from table(dbms_xplan.display_cursor('1a914ws3ggfsn'));
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------
SQL_ID  1a914ws3ggfsn, child number 0
-------------------------------------
SELECT  * FROM t1, t2 WHERE t1.id = t2.t1_id AND t1.n in(18,19)


Plan hash value: 3532430033
-------------------------------------------------------------------------------------------
| Id  | Operation                      | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |          |       |       |     6 (100)|          |
|   1 |  NESTED LOOPS                  |          |       |       |            |          |
|   2 |   NESTED LOOPS                 |          |     2 |  8138 |     6   (0)| 00:00:01 |
|   3 |    INLIST ITERATOR             |          |       |       |            |          |
|   4 |     TABLE ACCESS BY INDEX ROWID| T1       |     2 |  4056 |     2   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | T1_N     |     1 |       |     1   (0)| 00:00:01 |
|*  6 |    INDEX RANGE SCAN            | T2_T1_ID |     1 |       |     1   (0)| 00:00:01 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | T2       |     1 |  2041 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------


   5 - access(("T1"."N"=18 OR "T1"."N"=19))
   6 - access("T1"."ID"="T2"."T1_ID")


Note
-----
   - dynamic sampling used for this statement (level=2)
   
/*   
--优点：1.知道sql_id立即可得到执行计划，和explain plan for 一样无需执行；
        2.可以得到真实的执行计划。（停，等等，啥真实的，刚才这几个套路中，还有假的执行计划的吗？)
        
                 
--缺陷  1.没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；
        2.无法判断是处理了多少行；  
        3.无法判断表被访问了多少次。
        
*/        






----方法5(10046TRACE）
/*


  步骤1：alter session set events '10046 trace name context  forever,level 12'; （开启跟踪）
  步骤2：执行你的语句
  步骤3：alter session set events '10046 trace name context off';   （关闭跟踪）
  步骤4：找到跟踪后产生的文件
  步骤5：tkprof  trc文件  目标文件  sys=no sort=prsela,exeela,fchela  （格式化命令）     


*/
set autotace off
alter session set statistics_level=typical;     
alter session set events '10046 trace name context  forever,level 12';


SELECT  *
FROM t1, t2
WHERE t1.id = t2.t1_id
AND t1.n in(18,19);   
   
alter session set events '10046 trace name context off';   
select d.value
|| '/'
|| LOWER (RTRIM(i.INSTANCE, CHR(0)))
|| '_ora_'
|| p.spid
|| '.trc' trace_file_name
from (select p.spid
      from v$mystat m,v$session s, v$process p
      where  m.statistic#=1 and s.sid=m.sid and p.addr=s.paddr) p,
      (select t.INSTANCE
       FROM v$thread t,v$parameter v
       WHERE v.name='thread'
       AND(v.VALUE=0 OR t.thread#=to_number(v.value))) i,
       (select value
       from v$parameter
       where name='user_dump_dest') d;


exit      
 
tkprof d:\oracle\diag\rdbms\test11g\test11g\trace/test11g_ora_2492.trc    d:\10046.txt  sys=no sort=prsela,exeela,fchela       


SELECT  *
FROM t1, t2
WHERE t1.id = t2.t1_id
AND t1.n in(18,19)


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0         12          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0         12          0           2


Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 94  


Rows     Row Source Operation
-------  ---------------------------------------------------
      2  NESTED LOOPS  (cr=12 pr=0 pw=0 time=0 us)
      2   NESTED LOOPS  (cr=10 pr=0 pw=0 time=48 us cost=6 size=8138 card=2)
      2    INLIST ITERATOR  (cr=5 pr=0 pw=0 time=16 us)
      2     TABLE ACCESS BY INDEX ROWID T1 (cr=5 pr=0 pw=0 time=0 us cost=2 size=4056 card=2)
      2      INDEX RANGE SCAN T1_N (cr=3 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 108621)
      2    INDEX RANGE SCAN T2_T1_ID (cr=5 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 108622)
      2   TABLE ACCESS BY INDEX ROWID T2 (cr=2 pr=0 pw=0 time=0 us cost=2 size=2041 card=1)




Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       2        0.00          0.00
  SQL*Net message from client                     2        1.31          1.31
  
/*
--优点：1.可以看出SQL语句对应的等待事件
        2.如果SQL语句中有函数调用，SQL中有SQL，将会都被列出，无处遁形。
        3.可以方便的看出处理的行数，产生的物理逻辑读。
        4.可以方便的看出解析时间和执行时间。
        5.可以跟踪整个程序包
        
        
                 
--缺陷: 1.步骤繁琐，比较麻烦
        2.无法判断表被访问了多少次。
        3.执行计划中的谓词部分不能清晰的展现出来。
        
*/   
        
        
        
6. awrsqrpt.sql   


/*
  步骤1：@?/rdbms/admin/awrsqrpt.sql
  步骤2：选择你要的断点（begin snap 和end snap)
  步骤3：输入你的sql_id     
*/
       

Oracle获取执行计划的6种方法
林世广
11-08 1万+
Oracle获取执行计划的6种方法
mysql如何进行取样_Oracle 中的动态采样（dynamic sampling）相关示例
weixin_33997127的博客
02-02 444
1.1首先回顾下动态采样(dynamic sampling)的相关知识点 这个特性，使数据库随机的扫描表中少量的block，用来增强数据库的统计信息。 1.1.1 目的 动态采样增加了那些丢失的或者不足的优化器统计信息。使用动态采样可以让优化器更好的选择谓词。动态采样能够1.1首先回顾下动态采样(dynamic sampling)的相关知识点这个特性，使数据库随机的扫描表中少量的block，用来增...
查看执行计划的6种方法以及各个方法的优缺点
qq_22083251的博客
06-15 1371
--环境构造 --研究Nested Loops Join访问次数前准备工作 DROP TABLE t1 CASCADE CONSTRAINTS PURGE; DROP TABLE t2 CASCADE CONSTRAINTS PURGE; CREATE TABLE t1 ( id NUMBER NOT NULL, n NUMBER, contents VARCHAR2(4000) ) ; CREATE TABLE t2 ( id NUMBER NOT N...
oracle几种执行计划哪种比较看的过程透
wtfsb的博客
07-19 184
如果想查看某个SQL多个执行计划的情况，只能用方法4：dbms_xplan.display_cursor或方法6：awrsqrpt.sql。跟踪某条SQL最简单的方法是方法1：explain plan for，其次是方法2：set autotrace on。若想看到真实的执行计划，不受上面因素的限制，只能用方法3：set autotrace traceonly。如果SQL中含有函数，函数中有含有SQL，即存在多层调用，想准确分析只能用方法5：10046追踪。
临时表空间实验笔记
无咎的博客
12-13 277
实验数据库版本： 11.2.0.4 实验内容： 1、在临时表空间中新建两种类型的临时表，做相应操作； 2、对两种类型的临时表以及普通表进行增删操作，观察性能消耗； 实验结果： 三种类型的表的增改操作，只在redo的产生上有差异； 新增的情况下，事务级临时表 普通标； 使用delete删除的情况下，事务级临时表 实验结论：
【ORACLE Explain 详解】
热门推荐
qq_41443695的博客
11-23 2万+
ORACLE Explain 详解前言1.什么是执行计划？2.怎么查看执行计划？3.怎么看懂Oracle执行计划3.1explain执行顺序3.2访问数据的方法3.2.1全表扫描（TABLE ACCESS FULL）3.2.2ROWID扫描（TABLE ACCESS BY ROWID）3.2.3访问索引（TABLE ACCESS BY INDEX SCAN）索引唯一扫描（INDEX UNIQUE SCAN）索引范围扫描（INDEX RANGE SCAN）索引全扫描（INDEX FULL SCAN）索引快速全
Excel获取行信息——获取ROW、ROWS函数及其实例
weixin_50853979的博客
04-23 1万+
目录 1.ROW函数 （1）语法：ROW(reference) 即ROW([参照区域]) （2）作用：获取单元格或单元格区域的行序号 （3）实例 2.ROWS函数 （1）语法：ROWS(array) 即ROWS(数组) （2）作用：返回数组或引用的行数。 （3）实例 3.ROW函数与ROWS函数的区别 1.ROW函数 （1）语法：ROW(reference) 即ROW([参照区域]) 参数说明 reference： 需要得到其行号的单元格或单元格区域。如果省略..
oracle获取执行计划全部方法
12-24
### Oracle 获取执行计划全部方法详解 #### 方法一：Explain Plan for 方式 - **应用场景**：当某个 SQL 查询执行时间过长甚至无法返回结果时，这种方法尤其适用。 - **步骤**： 1. 使用 `EXPLAIN PLAN FOR` 命令...
Oracle获取执行计划
最新发布
02-26
嗯，用户问的是关于Oracle获取执行计划的方法，我需要详细介绍一下。首先，我得回想一下Oracle中常用的几种获取执行计划的方式，比如EXPLAIN PLAN命令、AUTOTRACE、DBMS_XPLAN包，还有SQL*Plus里的那些工具。可能还...
Oracle中一次查询多表记录数的3种方式.pdf
10-09
两步查询法的基本思路是首先构建一个包含表名和COUNT(*)函数的查询列表，然后执行这个列表以获取每个表的记录数。例如，对于SCOTT的DEPT表，你可以构建如下查询： ```sql SELECT 'DEPT' AS tablename, COUNT(*) AS ...
oracle的执行计划6,oracle学习笔记6: SQL执行计划
weixin_34486302的博客
04-06 503
解释计划语句explain plan用来显示优化器为sql语句选择的执行计划。SQL执行计划set autotrace off;set autotrace traceonly;explain plan forselect e.last_name||','||e.first_name as full_name,e.phone_number,e.email,e.department_id,d.depa...
Oracle执行计划的详细读法
ckxm3948的博客
04-20 1285
现在沉迷优化，所以我来分享一下我这段时间对于执行计划的解读，如果有什么不对的地方，希望大家不吝赐教。 废话不多说，我先上一条语句，因为我觉得这条比较典型，所以我们就先用这条的执行计划来解读下执行计划。 ...
Oracle执行计划 讲解（二）
guanyi的博客
09-17 704
现在我们讲讲oracle执行计划里面每个参数的含义 我们以下面的一个例子来讲解 这里做个补充：trace的类型一共有以下几种 序号 命令 解释 1 SET AUTOTRACE OFF 此为默认值，即关闭Autotrace 2 SET AUTOTRACE ON EXPLAIN 只显示执行计划 3 SET AUTOTRACE ON STAT
Oracle执行计划filter下多个节点的优化
coco3600的博客
07-03 744
Oracle执行计划filter下多个节点的优化 FILTER操作是执行计划中常见的操作，这种操作有两种情况： l只有一个子节点，那么就是简单过滤操作。 ...
sql语句之坑 连接查询的两种方式:left join 和 另一个
java0day01的博客
11-03 353
--以下两条语句查询结果一样 select * from t_gasbrand t1 left join t_userfiles t2 on t1.id = t2.f_gasbrand_id where t1.id = 17 --注意这里必须是where不能是and!!!where是取交集 select * from t_gasbrand t1,t_userfiles t2 where t1.id = t2.f_gasbrand_id and t1.id = 17 --如果这样写就错误了 s
Oracle数据库性能优化 -非空约束重要性全表扫描的性能提升
oradbm的博客
09-02 696
1.1测试现象 CREATE TABLE T1 AS SELECT OBJECT_ID,OBJECT_NAME FROM DBA_OBJECTS; CREATE TABLE T2 AS SELECT OBJECT_ID,OBJECT_NAME FROM DBA_OBJECTS; CREATE INDEX IDX1 ON T1(OBJECT_ID); EXPLA...
Oracle索引梳理系列（八）- 索引扫描类型及分析（高效索引必备知识）
weixin_30527423的博客
10-20 301
版权声明：本文发布于http://www.cnblogs.com/yumiko/，版权由Yumiko_sunny所有，欢迎转载。转载时，请在文章明显位置注明原文链接。若在未经作者同意的情况下，将本文内容用于商业用途，将保留追究其法律责任的权利。如果有问题，请以邮箱方式联系作者（793113046@qq.com）。 理解oracle索引扫描类型的特点以及具体触发的条件，对于通过合理地使用...
Oracle index】SQL语句无法走索引的一些情况分析及语句改写思路
蘑菇丁的专栏
12-18 1271
因为优化器还不够强大，还有很多限制，或者因为一些逻辑原因，分析认为SQL要走索引比较好，但是事实却无法正确利用索引。这时候，除了给ORACLE需要的统计信息之外，写的SQL必须要能够给优化器足够多的额外有效信息，让优化器能够选择更好的执行计划。 要让给优化器正确使用上需要的索引，要考虑两点： 1).如何避免优化器的限制 2).根据业务数据特点改写SQL语句       说明：这里说的走不
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值