执行计划中常见index访问方式

最新推荐文章于 2024-04-02 23:58:41 发布
最新推荐文章于 2024-04-02 23:58:41 发布
阅读量523 收藏
点赞数
分类专栏： 索引

文章来自：http://www.xifenfei.com/2968.html

SQL>  create table test as select object_id,object_name from dba_objects;
 create table test as select object_id,object_name from dba_objects;

Table created.
SQL>  create index i_t_object_id on test(object_id);


Index created.

SQL>  exec dbms_stats.gather_table_stats(USER,'TEST',cascade=>true);


PL/SQL procedure successfully completed.

SQL> desc test
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OBJECT_ID                                          NUMBER
 OBJECT_NAME                                        VARCHAR2(128)


table access full

SQL> SET AUTOT TRACE EXP STAT
SQL>  SELECT OBJECT_ID FROM test;

72516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 72516 |   354K|    95   (0)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| TEST | 72516 |   354K|    95   (0)| 00:00:02 |
--------------------------------------------------------------------------


Statistics
----------------------------------------------------------
        128  recursive calls
          0  db block gets
       5176  consistent gets
          0  physical reads
          0  redo size
    1324315  bytes sent via SQL*Net to client
      53697  bytes received via SQL*Net from client
       4836  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
      72516  rows processed



SQL> select /*+ index(T i_t_object_id) */ object_id from test;

72516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 72516 |   354K|    95   (0)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| TEST | 72516 |   354K|    95   (0)| 00:00:02 |
--------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       5160  consistent gets
          0  physical reads
          0  redo size
    1324315  bytes sent via SQL*Net to client
      53697  bytes received via SQL*Net from client
       4836  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      72516  rows processed

  从上面的执行计划中可知,此时走了全表扫描. 由于我们需要查询的列为object_id,因此理论上只需要读取索引就应该可以返回所有数据,而此时为什么是全表扫描呢？ 这是因为NULL值与索引的特性所决定的.即null值不会被存储到B树索引.因此应该为表 t_xifenfei 的列 object_id 添加 not null 约束.


  INDEX FAST FULL SCAN

SQL> alter table test modify(object_id not null);


Table altered.


SQL> SELECT  object_id from  test;


72516 rows selected.




Execution Plan
----------------------------------------------------------
Plan hash value: 2036340805


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


| Id  | Operation            | Name          | Rows  | Bytes | Cost (%CPU)| Time
     |


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


|   0 | SELECT STATEMENT     |               | 72516 |   354K|    45   (0)| 00:0
0:01 |


|   1 |  INDEX FAST FULL SCAN| I_T_OBJECT_ID | 72516 |   354K|    45   (0)| 00:0
0:01 |


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






Statistics
----------------------------------------------------------
        128  recursive calls
          0  db block gets
       5010  consistent gets
          0  physical reads
          0  redo size
    1324315  bytes sent via SQL*Net to client
      53697  bytes received via SQL*Net from client
       4836  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
      72516  rows processed


  INDEX FAST FULL SCAN:当在高速缓存中没有找到所需的索引块时,则根据db_file_multiblock_read_count的值进行多块读操作.对于索引的分支结构只是简单的获取,然后扫描所有的叶结点.其结果是导致索引结构没有访问,获取的数据没有根据索引键的顺序排序.INDEX FAST FULL SCAN使用multiblock_read,故产生db file scattered reads 事件


INDEX RANGE SCAN

SQL>  select object_id from test where object_id<10;

8 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2197008162

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

| Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time
 |

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

|   0 | SELECT STATEMENT |               |     8 |    40 |     2   (0)| 00:00:01
 |

|*  1 |  INDEX RANGE SCAN| I_T_OBJECT_ID |     8 |    40 |     2   (0)| 00:00:01
 |

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


Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("OBJECT_ID"<10)


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        629  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          8  rows processed


INDEX FULL SCAN 

SQL>    select /*+ index(T i_t_object_id) */ object_id from test t;

72516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 431110666

----------------------------------------------------------------------------------
| Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |               | 72516 |   354K|   162   (0)| 00:00:02 |
|   1 |  INDEX FULL SCAN | I_T_OBJECT_ID | 72516 |   354K|   162   (0)| 00:00:02 |
----------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       4986  consistent gets
          0  physical reads
          0  redo size
    1324315  bytes sent via SQL*Net to client
      53697  bytes received via SQL*Net from client
       4836  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      72516  rows processed


INDEX列ORDER BY 

SQL>     SELECT OBJECT_ID FROM Test order by object_id ;

72516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 431110666

----------------------------------------------------------------------------------
| Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |               | 72516 |   354K|   162   (0)| 00:00:02 |
|   1 |  INDEX FULL SCAN | I_T_OBJECT_ID | 72516 |   354K|   162   (0)| 00:00:02 |
----------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       4986  consistent gets
          0  physical reads
          0  redo size
    1324315  bytes sent via SQL*Net to client
      53697  bytes received via SQL*Net from client
       4836  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      72516  rows processed

SQL>      SELECT OBJECT_ID FROM Test order by object_id desc;

72516 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2808014233

--------------------------------------------------------------------------------------------
| Id  | Operation                  | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |               | 72516 |   354K|   162   (0)| 00:00:02 |
|   1 |  INDEX FULL SCAN DESCENDING| I_T_OBJECT_ID | 72516 |   354K|   162   (0)| 00:00:02 |
--------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       4987  consistent gets
          0  physical reads
          0  redo size
    1324315  bytes sent via SQL*Net to client
      53697  bytes received via SQL*Net from client
       4836  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      72516  rows processed

对于index 列排序,默认情况下会使用INDEX FULL SCAN/INDEX FULL SCAN DESCENDING而不选择使用INDEX FAST FULL SCAN,因为INDEX FAST FULL SCAN获得数据后,还需要做一次SORT ORDER BY操作 


SQL>      SELECT  max(object_id) FROM Test;


Execution Plan
----------------------------------------------------------
Plan hash value: 2939893782

--------------------------------------------------------------------------------------------
| Id  | Operation                  | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |               |     1 |     5 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE            |               |     1 |     5 |            |          |
|   2 |   INDEX FULL SCAN (MIN/MAX)| I_T_OBJECT_ID |     1 |     5 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        534  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

sort aggregate通常发生在使用一些聚合函数的时候,sum(),avg(),min(),max(),count()等等,实际上sort aggregate不做真正的sort,并不会用到排序空间,而是通过一个全局变量＋全表或全索引扫描来实现.这样的操作在默认情况下使用INDEX FAST FULL SCAN








huangliang0703
关注
专栏目录
Oracle查看执行计划
itmyhome的专栏
03-20 1127
通过执行计划查看SQL语句是否使用了索引 1、生成执行计划 explain plan for sql语句 2、查看执行计划结果 select plan_table_output from TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE')); 如上图所示：TABLE ACCESS FULL为全表扫描 几种常见的索引类型扫描： 一、index unique sca...
Explain执行计划详解
IT王小二的博客
01-24 3174
作者：IT王小二 博客：https://itwxe.com 一条查询 SQL 语句为什么会执行很慢？执行的时候走了什么索引？多表查询的时候 SQL 大体执行流程是怎么样的？Explain 执行计划详解给各位客官一一道来。 一、示例MySQL安装方式和版本 首先需要 MySQL 安装的客官看这两篇，小二演示使用的是 Docker 的安装方式： Linux(CentOS7)下二进制安装MySQL5.7.26 Docker搭建MySQL并挂载数据 小二安装完的 MySQL 数据库版本为 5.7.36。 二.
执行计划中常见index访问方式(转)
weixin_34128237的博客
09-01 134
近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本篇文章仅仅是为了测试hint对index的影响,而不是说明走各种index方式的好坏.参考: INDEX FULL SCAN vs INDEX FAST FULL SCAN创建表模拟测试 ...
mysql 索引 index、执行计划explain、索引失效问题、聚簇索引
weixuan_的博客
05-31 381
mysql 索引 index、执行计划explain、索引失效问题、聚簇索引
oracle执行计划走索引的方式,执行计划中常见index访问方式 – 提供7*24专业数据库(Oracle,SQL Server,MySQL等)恢复和Oracle技术服务@Tel:+86 13429...
weixin_36482976的博客
04-06 261
近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本篇文章仅仅是为了测试hint对index的影响,而不是说明走各种index方式的好坏.参考: INDEX FULL SCAN vs INDEX FAST FULL SCAN创建表模拟测试SQL>...
mysql高级之explain执行计划详解以及show index各项所代表的意思
神级莫甘娜的技术博客
07-01 760
1、mysql explain查询计划中各项参数的意思： 2、查看mysql中的index索引： SHOW INDEX FROM tbl_name [FROM db_name] SHOW INDEX会返回表索引信息。其格式与ODBC中的SQLStatistics调用相似。 SHOW INDEX会返回以下字段： · Table 表的名称。 · Non_unique 如果索引不能包括重复词，则为0...
SQLserver中执行计划的名词解释Table Scan, Index Scan, Index Seek
hzp666的博客
08-13 1996
原文：https://www.cnblogs.com/xwdreamer/archive/2012/07/06/2579504.html Sql Server中的表访问方式Table Scan, Index Scan, Index Seek 0.参考文献 Table Scan, Index Scan, Index Seek SQL SERVER – Index Seek vs. Index Scan – Diffefence and Usage – A Simple Note oracle表.
oracle执行计划详解
12-27
在Oracle中，可以通过两种主要的方式查看执行计划：使用EXPLAIN PLAN命令和查询V$SQL_PLAN视图。EXPLAIN PLAN命令能够提供一条SQL语句的执行计划，但它不会实际执行这条语句。V$SQL_PLAN视图则提供了一个游标已编译...
执行计划收集与分析
08-27
执行计划包括了访问表的方式（如索引扫描或全表扫描）、连接表的方法（如嵌套循环连接或哈希连接），以及其他用于优化查询执行效率的策略。 #### 二、查询优化器的行为 Oracle数据库的查询优化器负责生成执行计划...
【Cypher语言】id含义、index、属性唯一性约束、执行计划
XiaoCai
11-18 1768
1. id的含义 Cypher每个节点或Relation都有一个系统分配的id，从0开始递增，全局唯一！ 例如： Create(a:Person{id:123}),此ID不是系统分配的id，且该语句不会出现关键字错误。 2. 索引index ----创建索引 create index on:Person(id) ----删除索引 drop index on:Person(id) 不需要给索引起名称，只需要设置索引字段即可 通过该字段的查询都走索引，而关系型数据库中，索引字段套一层函数的话，基本上不走索
Oracle 执行计划中常见index访问方式
congjian0578的博客
12-14 298
========================================= ========ZMOS_02=========================== ==============...
mysql---索引与执行计划
程序yuan同学
11-01 483
文章目录索引入门什么是索引MySQL中的索引索引的分类基础语法执行语法什么是执行语法执行计划的作用执行计划的语法执行计划详解 索引入门 什么是索引 MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。 可以得到索引的本质：索引是数据结构。 上面的理解比较抽象，举一个例子，平时看任何一本书，首先看到的都是目录，通过目录去查询书籍里面的内容会非常的迅速。 上图就是一本金瓶梅的书，书籍的目录是按顺序放置的，有第一节，第二节它本身就是一种顺序存放的数据结构，是一种顺序结构。 另
oracle执行计划没有执行索引,求指教，分区表执行计划为什么不走local索引
weixin_39543655的博客
04-03 189
去掉order by后重新实验的结果ESB_MSG_LOG表不再走global索引了SQL ID: ag6vd5mf6a502 Plan Hash: 1689797747select *from(select id,SOURCESYSTEM,transtime,FLOWNAME from ESB_MSG_LOG where id<879248and transtimecall cou...
MySQL-执行计划、explain关键字查询执行计划以及explain案例分析
最新发布
小孔靠得住的博客
04-02 2248
MySQL 的执行计划（Execution Plan）是数据库查询优化器生成的一种指导性信息，它描述了 MySQL 执行查询时所采用的具体执行策略。执行计划通常由 MySQL 的查询优化器根据查询语句、表结构、索引等信息进行生成，并且用于指导 MySQL 数据库引擎执行查询操作。
MySQL执行计划与索引规范
根号三
03-07 765
一、MySQL explain执行计划详解 使用explain查看MySQL的执行计划时，会看到下面的输出结果。 首先，解释一下每一列的意思及常见的值。 1、id 在包含连接查询、子查询的语句中，使用explain查看执行计划时，会有多条结果。id越大的越先执行，id相等时，从上往下依次执行，id为NULL表示这是一个结果集，不需要使用它来查询。 2、select_type sel
索引反向使用案例，加index_desc hint
weixin_30566111的博客
11-11 79
drop index idx_t;create index idx_t on t(owner desc,object_type asc);select /*+index(a,idx_t)*/ * from t a order by owner desc ,object_type asc;执行计划----------------------------------------------------...
Mysql：索引分析及优化
weixin_42155491的博客
04-24 507
索引基本知识 什么是索引 索引是一种数据结构，可以提高查找效率。可以理解为：索引是一个排好序的快速查找数据结构。 我们平时说的索引，没有特殊说明，都是B+Tree结构。 索引实际上也是一张表，保存了主键和索引字段并指向实体表的记录。 创建索引create index [索引名] on [表名] ([列名]) 删除索引drop index [索引名] on [表名] 查看索引show in...
史上最详细的mysql底层和explan type和type中index和all的区别
weixin_45473171的博客
11-21 7001
背景： 前几天我朋友问我一个问题,mysql的explan(执行计划)中type的index和all是不是压根没有区别，而且还推了几个博主的链接给我，我看了之后感觉有些无奈，有些博主自己都没有太搞清楚就出来科普让很多人都走歪道了，于是就有了这篇文章，花费了我一整天的时间(本文讨论的是innodb存储引擎) mysql的explan： 什么是explan呢，相信看这篇文章的各位已经至少对mysql有了初步的了解，甚至在开发过程中也会用explan进行sql的优化，explan是mysql执行计划的关键词，在s
执行计划中的extra有多少中方式
06-11
执行计划中的extra字段是用来描述MySQL执行查询时涉及到的一些额外信息的。根据不同的查询类型和执行计划，extra字段可能会有不同的取值。一些常见的extra取值包括： 1. Using index：表示使用了覆盖索引，避免了回...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值