[总结]关于index range scans & INDEX (FAST FULL SCAN)

Q:

对于通过index range scans访问的表可以通过按索引重建表来提高效率,但是为什么通过INDEX (FAST FULL SCAN) 访问的表不能通过重建表来提高效率.

Biti:

index rang scan 是根据索引的叶子block中数据去访问表，和 key 大小顺序一致

index FFS 是根据索引的 extent /block 顺序去访问所有索引block，包括所有叶子和枝节点，这个顺序并不和 key 顺序一致。

 

Xzh2000:

 

应该可以的.
index rebuild后碎片消除,
肯定会提高效率

Q:

通过index range scans访问的表可以通过按索引重建表来提高效率, 是因为根据索引的叶子block中数据去访问表，和 key 大小顺序一致,还是重建表以后访问的数据块更少.

Biti:

重整表当然可能回解决碎片问题（假如有碎片的话）

但那得看人家说的是啥啊，明显不是指碎片问题

xzh2000:

 

"通过index range scans访问的表可以通过按索引重建表来提高效率"
这里的按索引重建表是什么意思？

 

Biti:

 

insert into table select * from xxx order by INDEX_KEYS;


oracle 在920 开始，优化器对表顺序和索引key顺序基本一致的表，做了特别的优化处理，即使根据索引访问整个表，逻辑读比原来也大大降低。

 

Xzh2000:

INDEX FFS是说如果可以从INDEX上获取某次访问所需要的数据，
那就执行INDEX FFS，不需要去访问表；如果不可以从INDEX上获
取某次访问的数据，它可能会执行INDEX FULL SCAN，然后再通过ROWID去访问DATA BLOCK

 

Q:

 

通过index range scans访问的表可以通过按索引重建表来提高效率, 是因为根据索引的叶子block中数据去访问表，和 key 大小顺序一致,还是重建表以后访问的数据块更少? 它的原理是什么?

 

quote:

最初由 xzh2000 发布


INDEX FFS是说如果可以从INDEX上获取某次访问所需要的数据，
那就执行INDEX FFS，不需要去访问表；如果不可以从INDEX上获
取某次访问的数据，它可能会执行INDEX FULL SCAN，然后再通过ROWID去访问DATA BLOCK

Biti:

sorry ,我在这里错把 index fast full scan 当成 index full scan 了。


但是 按照索引来重建表就是指的 按照索引顺序重新建立表，和 IOT 没有必然联系。IOT 并不是随便使用的，不同版本有不同的不少限制条件。如果你本来就有个 主键，又如何根据新的索引来做 IOT ?



如果你要问重建了表过了一段时间之后顺序又不好了怎么办，那可以考虑再重建。


index fast full scan 只访问索引，所以和表无关。

 

最初由 wwllzpz 发布
通过index range scans访问的表可以通过按索引重建表来提高效率, 是因为根据索引的叶子block中数据去访问表，和 key 大小顺序一致,还是重建表以后访问的数据块更少? 它的原理是什么?

这个问题和 碎片无关。即使根本没有碎片也成。

这样做后在复杂环境下可能会大大减少 IO ，在 920 会大大减少 逻辑读，你做个测试就知道了。

 

Q:

测试已经做过了,确实可以减少逻辑读,但是这样重建表可以减少IO的原理我看了一些资料还是不很清楚.麻烦biti_rainy 解释一下?

 

Biti:

最初由 wwllzpz 发布

测试已经做过了,确实可以减少逻辑读,但是这样重建表可以减少IO的原理我看了一些资料还是不很清楚.麻烦biti_rainy 解释一下?

1: 如果你只读一部分数据，假设20% ，如果表数据顺序混乱，实际上可能把整个表都读进来了。如果表顺序和索引一致，则只需要读进 20%的表的block就够了。这是简单情况。


2：复杂情况下，顺序混乱的时候 block 可能在整个查询的不同时间点多次反复访问，当再次要访问这个块的时候说不定已经被换出去了，或者被修改过了，那代价更大。 而如果顺序一样，对同一个block的访问集中在一段连续的很短的时间内，变数少，不会对同一个block产生多次 IO

 

 

husthxd:

quote:

最初由 rchsh 发布
根据索引重建表以后，这样相临的数据就集中在很少的数据块中了，所以可以减少数据块的读取

从表统计信息中的cluster_factor可以判断是否有很好的聚集性.
btw:
记得有个文档上说ffs比fs快的一个原因是使用了多块读.
不清楚索引的多块读是否跟表block的多块读的机理是否一致?

 

Biti:

 

FFS和FTS是一样的，所以这样出来的数据也并不是有序的。只是索引比表小，快一些而已。


如果你创建一个一两个数字字段的表，走FFS，反而比FTS慢了，因为索引比表还大

 

INDEX fast full scan 和 index range scan 根本就是不同的概念，你需要先把原理弄清楚再来看表象

index range scan 是 根据叶子节点的顺序去寻找数据，数据出来和索引顺序是一致的排好顺序的，一次读一个索引block和一个数据block

index fast full scan 是根据索引 segment 的 extent 去搜索的，这个跟 FTS 的原理类似，不过 table segment 换成了 index segment ,一次读可以是连续的多个 index block ，这样出来的数据顺序和 索引顺序并不一致。

而我们通常说的利用不上索引 指的 是 index range scan or other index scan ,不是 index fast full scan 。
index fast full scan 的前提是，数据肯定在索引中有（比如not null 的字段，或者复合索引，bitmap索引等），然后 索引 segment比表 segment小，通过索引segment 能得到所需要数据，而不用去读 任何表的block，这样 IO 将减少。

 

Fast Full Index Scans :
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 NULL constraint. A fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation, because the data is not ordered by the index key. It reads the entire index using multiblock reads, unlike a full index scan, and can be parallelized.

Fast full scan is available only with the CBO. You can specify it with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. Fast full index scans cannot be performed against bitmap indexes.

A fast full scan is faster than a normal full index scan in that it can use multiblock I/O and can be parallelized just like a table scan.

http://download-west.oracle.com/doc...imops.htm#51111



Full Table Scans :
This type of scan reads all rows from a table and filters out those that do not meet the selection criteria. During a full table scan, all blocks in the table that are under the high water mark are scanned. Each row is examined to determine whether it satisfies the statement's WHERE clause.

When Oracle performs a full table scan, the blocks are read sequentially. Because the blocks are adjacent, I/O calls larger than a single block can be used to speed up the process. The size of the read calls range from one block to the number of blocks indicated by the initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT. Using multiblock reads means a full table scan can be performed very efficiently. Each block is read only once.

http://download-west.oracle.com/doc...imops.htm#44852

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6906/viewspace-21696/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6906/viewspace-21696/