oracle full table scan,(转)索引扫描还是全表扫描（Index Scan Or Full Table Scan）

作者： | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及

链接：

在大多数时候，大家都会认为Sql语句中走Index Scan比Full Table Scan快，我前面也走进了这样的误区(对Index Scan的理解不够)。这两天重新复习了一下这方面内容，并整理了一下。[@more@]

当Oracle Optimizer(优化器)没有选择Index Scan而选择了Full Table Scan的时候一般会是由两种情况：

1、表没有Analyze，Optimizer得不到statistics(统计)数据，无法评估而选择了Full Table Scan

2、Optimizer通过得到的statistics数据后评估认为Full Table Scan将比Index Scan更快

对于第一种情况当然很好理解，而且只要运行简单的Analyze命令就好了，然后就是Oracle Optimizer按照他的一系列算法来进行选择了，到这里其实也同样可能会遇到第二种情况，关键还是要看Optimizer的评估结果。

Oracle Optimizer在评估一个Index的Cost(开销)时候，有两个主要的关键指标。

Oracle官方语称为：CF(Clustering Factor)和FF(Filtering Factor)。

用通俗一点的话来理解，CF就是指每读入一个Index Block，对应需要读多少个Data Block。而FF呢就是该Sql最终需要读取的记录集占到了整个Table中记录总条数的百分比。

由于通过Index来读取数据的时候是需要先读取Index Block然后再通过Rowid读取相应的Data Block，每读取一条记录都需要读取一次数据块(这里表述有点问题，已经在中解释)，这样极有可能出现对同一个Data Block读取多次的情况。使用索引读取数据需要读取的Block数目据说公式大约是这样的(只是据说)：

FF ×(CF × Index Blocks)

而对于Full Table Scan，是通过db_file_multiblock_read_count设定的值进行连续读取整个Table的所有(HWM以下)数据块。

所以当需要读取表中数据越多的时候(也即是FF值比较大的时候)，Index

Scan花销自然也会越大。而CF值主要受到索引中数据的排列方式影响，通常在 索引刚建立时，索引中的记录与表中的记录有良好的对应关系，CF

都很小；在表经过大量的插入、修改后，这种对应关系越来越乱，CF 也越来越大。这时候就需要Rebuild

Index。如果出现了一个Sql语句在最初时候走了Index而运行一段时间后突然变成了Full Table

Scan的情况的时候，一般都是由于CF值变大的缘故。通过Rebuild Index就可以解决。而FF 则是Oracle 根据

statistics数据所做的估计，所以需要经常Analyze

Table来更新表的statistics来让Optimizer做出正确的估计而得出最佳的执行计划。