index_ss hint 使用的执行计划变化对比

index_ss  hint 使用的执行计划变化对比

其中 buffer 代表:当前操作中发生的内存读次数,包含一致性读和当前读

虽然 emp 表记录数不多,但是buffer 读内存的次数差别还是有点大的

SQL>  select  job from emp where ename=‘SMITH‘;

JOB

------------------

CLERK

SQL> select * from table(dbms_xplan.display_cursor(null,null,‘allstats last‘))

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SQL_ID  at8ssqpn41css, child number 0

-------------------------------------

select /*+ index_ss(emp i_emp)*/ job from emp where ename=‘SMITH‘

Plan hash value: 3956160932

------------------------------------------------------------------------------------

| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |

------------------------------------------------------------------------------------

|*  1 |  TABLE ACCESS FULL| EMP  |      1 |      1 |      1 |00:00:00.01 |       8 |

------------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("ENAME"=‘SMITH‘)

17 rows selected.

----创建一个索引

SQL>  create index i_emp on emp(empno, ename);

Index created.

SQL> select /*+ index_ss(emp i_emp)*/ job from emp where ename=‘SMITH‘;

JOB

------------------

CLERK

SQL>  select * from table(dbms_xplan.display_cursor(null,null,‘allstats last‘))

2  ;

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SQL_ID  ck2pc7bpbzdz8, child number 0

-------------------------------------

select /*+ index_ss(emp i_emp)*/ job from emp where ename=‘SMITH‘

Plan hash value: 98078853

-----------------------------------------------------------------------------------------------

| Id  | Operation                   | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers |

-----------------------------------------------------------------------------------------------

|   1 |  TABLE ACCESS BY INDEX ROWID| EMP   |      1 |      1 |      1 |00:00:00.01 |       3 |

|*  2 |                 INDEX SKIP SCAN           | I_EMP |      1 |      1 |      1 |00:00:00.01 |       2 |

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("ENAME"=‘SMITH‘)

filter("ENAME"=‘SMITH‘)

19 rows selected.

时间: 2024-12-19 20:59:10

index_ss hint 使用的执行计划变化对比的相关文章

Oracle SQL执行计划基线总结(SQL Plan Baseline)

一.基础概念 Oracle 11g开始,提供了一种新的固定执行计划的方法,即SQL plan baseline,中文名SQL执行计划基线(简称基线),可以认为是OUTLINE(大纲)或者SQL PROFILE的改进版本,基本上它的主要作用可以归纳为如下两个: 1.稳定给定SQL语句的执行计划,防止执行环境或对象统计信息等等因子的改变对SQL语句的执行计划产生影响! 2.减少数据库中出现SQL语句性能退化的概率,理论上不允许一条语句切换到一个比已经执行过的执行计划慢很多的新的执行计划上! 注意:

稳定(固定)执行计划

sql执行计划为什么会变? 为什么我们的SQL语句执行计划会改变?如何才能稳定SQL语句的执行计划?要想回答上面的2个问题,我们就要首先知道SQL语句的执行计划是如何产生的,有那些因素影响执行计划的生成,只有了解了这些因素我们才能对症下药,稳定我们的SQL语句执行计划. 我们知道,一条SQL语句他的执行计划可能不止一个,数据库是 如何确定采用那条执行计划的呢?这是由数据库的优化器所决定,它的作用就是在所有可能的执行计划当中选择一个最'优'的执行计划.目前的数据库的优化器有 2种:基于规则的RBO

Oracle 11g 执行计划管理1

1. 执行计划管理的工作原理 1.1控制执行计划的稳定性 11g之前,可以使用存储大纲(stored outline)和SQL Profile来固定某条SQL语句的执行计划,防止由于执行计划发生变化而导致的性能下降. 11g开始,oracle引入了SQL执行计划管理,从而可以让系统自动的来控制SQL语句执行计划的稳定性,进而防止由于执行计划发生变化而导致的性能下降 1.2 11g执行计划管理 优化器会为所有执行次数超过一次的SQL语句维护该SQL语句的每个执行计划的历史列表(plan histo

Mongodb索引和执行计划 hint 慢查询

查询索引 索引存放在system.indexes集合中 > show tables address data person system.indexes 默认会为所有的ID建上索引 而且无法删除 > db.system.indexes.find() { "v" : 1, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "

简单对比查看执行计划的两种方法EXPLAIN PLAN 和 AUTOTRACE

EXPLAIN PLAN 和 AUTOTRACE 都可以查看执行计划. 值得一提的是:前者只是优化器通过读取数据字典的统计信息做出'最佳'访问路径判断,并没有真正去执行语句:后者是实际去执行了SQL语句,同时把访问记录数.执行计划.统计信息等打印出来. 下面粘出实验结果加以说明,注意对比两者的耗时: <p>SQL> CONNECT /AS SYSDBA Connected.</p><p>SQL> SET LINESIZE 300; SQL> SET T

使用hint优化Oracle的执行计划

背景: 某表忽然出现查询非常缓慢的情况,cost 100+ 秒以上:严重影响生产. 原SQL: explain plan for select * from ( select ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS, EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET

dblink导致执行计划出错,hint也无效

开发的同事发来一条语句,让我帮忙查看下ods和源端的结果是否一致.因为一下执行没出来,问开发人员,这个语句要跑2-3分钟. 因为他们是从本地用dblink连到ods的,我这里把dblink去掉直接从ods查看执行计划. SELECT XSY_CODE,--发展销售员编码 SLY_CODE,--受理销售员编码 XSD_CODE,--销售点编码 DZS_CODE,--店中商编码 JYZT_CODE--销售员所属经营主体编码 FROM (select /*+parallel(a,10) paralle

添加索引后SQL消耗量在执行计划中的变化

不同索引的执行效率也是不一样的,下面比较三条SQL语句在正常查询与建立普通索引与位图索引后的CPU消耗量的变化,目的为了是加强对索引的理解与运用 实验步骤: 1.创建有特点的大数据表.为了保证索引产生前后,查询效果的正确比对,应建立一个存在大量数据的测试表.这个测试表的数据来源于SYS模式下的all_objects视图,其中包括本数据库实例中的全部对象的基本描述,具体包括对象的所有者.对象名称.创建日期等信息.创建测试表的具体过程: 创建大数据表,sys用户下的all_objects表就比较适合

SQL SERVER 2014 下IF EXITS 居然引起执行计划变更的案例分享

这个问题是在SQL SERVER 2005 升级到SQL SERVER 2014的测试过程中一同事发现的.我觉得有点意思,遂稍微修改一下脚本展示出来,本来想构造这样的一个案例来演示,但是畏惧麻烦,遂直接贴上原表,希望Leader不要叼我(当然个人觉得真没啥,两张表名而已,真泄露不了啥信息). 脚本如下所示,非常简单的一段SQL语句,我将其分为SQL1.SQL2.SQL3.  其实SQL2.SQL3是差不多的,唯一的区别在于多了一个IF EXISTS DECLARE @Operation_Code