index full scan和index fast full scan区别

官档的解释:

Full Index Scan

In a full index scan, the database reads the entire index in order. A full index scan is available if a predicate (WHERE clause) in the SQL statement references a column in the index, and in some circumstances when no predicate is specified. A full scan can eliminate sorting because the data is ordered by index key.

原理:ORACLE定位到索引的ROOT BLOCK,然后到BRANCH BLOCK(如果有的话),再定位到第一个LEAF BLOCK, 然后根据LEAF BLOCK的双向链表顺序读取。它所读取的块都是有顺序的,也是经过排序的。

Fast Full Index Scan

A fast full index scan is a full index scan in which the database reads the index blocks in no particular order. The database accesses the data in the index itself, without accessing the table.

Fast full index scans are an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULLconstraint.

A fast full scan is faster than a normal full index scan because it can use multiblock I/O and can run in parallel just like a table scan.

The database cannot perform fast full index scans of bitmap indexes.

原理:从段头开始,读取包含位图块,ROOT BLOCK,所有的BRANCH BLOCK,LEAF BLOCK,读取的顺序完全有物理存储位置决定,并采取多块读,每次读取DB_FILE_MULTIBLOCK_READ_COUNT个块。查询某个表记录总数的时候,往往基于PRIMARY KEY的INDEX FAST FULL SCAN是最有效的。

测试COST:

SQL> create table t3 as select * from dba_objects;

表已创建。

SQL> create index t3_ix on t3(object_id);

索引已创建。

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

表已更改。

SQL> exec dbms_stats.gather_table_stats(‘SYS‘,‘T3‘);

PL/SQL 过程已成功完成。

SQL> set autot on
SQL> select count(*)  from t3;

COUNT(*)
----------
     72006

执行计划
----------------------------------------------------------
Plan hash value: 271548554

------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Cost (%CPU)| Time     |
------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     1 |   162   (0)| 00:00:02 |
|   1 |  SORT AGGREGATE  |       |     1 |            |          |
|   2 |   INDEX FULL SCAN| T3_IX | 63127 |   162   (0)| 00:00:02 |
------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)

SQL> select count(*)  from t3;

COUNT(*)
----------
     72006

执行计划
----------------------------------------------------------
Plan hash value: 2285970227

-----------------------------------------------------------------------
| Id  | Operation             | Name  | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT      |       |     1 |    62   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE       |       |     1 |            |          |
|   2 |   INDEX FAST FULL SCAN| T3_IX | 63127 |    62   (0)| 00:00:01 |
-----------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)

可以看到,indexl full scan的cost 为162,index fast full scan 的cost 为62,fast full scan的cost明显要低。

测试SORT:

SQL> select object_id  from t3 where rownum<10 order by object_id;

OBJECT_ID
----------
         2
         3
         4
         5
         6
         7
         8
         9
        10

已选择9行。

执行计划
----------------------------------------------------------
Plan hash value: 633445068

--------------------------------------------------------------------------
| Id  | Operation        | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT |       |     9 |    45 |     2   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY   |       |       |       |            |          |
|   2 |   INDEX FULL SCAN| T3_IX |     9 |    45 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

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

1 - filter(ROWNUM<10)

SQL> select object_id  from t3 where rownum<10 order by object_id;

OBJECT_ID
----------
         2
         3
         4
         5
         6
         7
         8
         9
        10

已选择9行。

执行计划
----------------------------------------------------------
Plan hash value: 512512221

----------------------------------------------------------------------------------------
| Id  | Operation              | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |       |     9 |    45 |       |   284   (2)| 00:00:04 |
|   1 |  SORT ORDER BY         |       |     9 |    45 |   856K|   284   (2)| 00:00:04 |
|*  2 |   COUNT STOPKEY        |       |       |       |       |            |          |
|   3 |    INDEX FAST FULL SCAN| T3_IX | 72006 |   351K|       |    61   (0)| 00:00:01 |
----------------------------------------------------------------------------------------

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

2 - filter(ROWNUM<10)

通过执行计划可以看到,fast_full_scan多了一个排序的步骤,而full scan没有这个排序的步骤,说明full scan的数据是根据索引键排好序的,而fast_full_scan的多块读导致其没有按照索引键排好序

原文地址:https://www.cnblogs.com/youngerger/p/9017951.html

时间: 2024-10-18 18:04:23

index full scan和index fast full scan区别的相关文章

Index Full Scan vs Index Fast Full Scan-1103

[Oracle] Index Full Scan vs Index Fast Full Scan作者:汪海 (Wanghai) 日期:14-Aug-2005 出处:http://spaces.msn.com/members/wzwanghai/ --------------------------------------------------------------------------------Index Full Scan vs Index Fast Full Scan index f

索引快速扫描(index fast full scan)

一.索引快速扫描(index fast full scan) 索引快速全扫描(INDEX FAST FULL SCAN)和索引全扫描(INDEX  FULL SCAN)极为类似,它也适用于所有类型的B树索引(包括唯一性索引和非唯一性索引).和索引全扫描一样,索引快速全扫描也需要扫描目标索引所有叶子块的所有索引行. 索引快速全扫描与索引全扫描相比有如下三点区别. (1)索引快速全扫描只适用于CBO. (2)索引快速全扫描可以使用多块读,也可以并行执行. (3)索引快速全扫描的执行结果不一定是有序的

$(obj).index(this)与$(this).index()异同讲解

$(this).index()在使用jQuery时出镜率非常高,在编写选项卡及轮播图等特效时经常用到,但$(obj).index(this)似乎有点陌生. 为便于理解,以下分两个使用场景加以分析. 场景一: 同级元素标签相同 <ul> <li>one</li> <li>two</li> <li>three</li> <li>four</li> </ul> <script> /

SQLite: Cannot bind argument at index 1 because the index is out of range. The statement has 0 param

SQLite: Cannot bind argument at index 1 because the index is out of range. The statement has 0 parameters SQLite出现了这样的错误 12-25 22:52:50.252: E/AndroidRuntime(813): Caused by: java.lang.IllegalArgumentException: Cannot bind argument at index 1 because

查找索引碎片Find Index Fragmentation Details – Slow Index Performance

SQL SERVER – 2005 – Find Index Fragmentation Details – Slow Index Performance Just a day ago, while using one index I was not able to get the desired performance from the table where it was applied. I just looked for its fragmentation and found it wa

Local prefixed index和Local nonprefixed index对select语句的性能影响分析

1.搞清楚两种索引的概念 在比较两种索引对select产生的影响之前,先要搞清楚,什么是Local prefixed index,什么叫Local nonprefixed index.其实,这两种索引,都是属于分区local索引,所以,这两种类型的索引,只有可能在分区表上才会出现. 1.1 什么是Local prefixed index 是指索引中的列,就是分区表的分区键列,或者是索引中的列,包含表的分区键值列,并且为前置位 置在索引最前部位置的本地分区索引. 例如,emp表是按时间范围分区的表

@Index用法——javax.persistence.Index

package com.springup.utiku.model; import java.io.Serializable; import javax.persistence.Entity; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.Index; import java

index控制器中的index操作

index.php类初始化以后,默认执行indexOp()操作: public function indexOp(){ //输出管理员信息 Tpl::output('admin_info',$this->getAdminInfo()); //getAdminInfo()继承于父类SystemControl //输出菜单 $this->getNav('',$top_nav,$left_nav,$map_nav); //获取菜单,在公共方法中 Tpl::output('top_nav',$top_

添加一个index(add an index)

想ES中存储数据,需要index--存储数据的地方,实际上,index就是一个指向若干物理shard的逻辑命名空间. shard就是更底层的工作单元,每个shard是一个Lucene的实例,每个shard在其控制范围内都是一个完整的搜索引擎.我们的文档被存储,并且被index到shard,但是应用程序是不和shard直接对话的而是和index进行通信. 由于shard是真正储存数据的地方,因此shard表示了ES在你的cluster中是怎么分布数据的.文档被存储在shard中,shard被分配到