在大多数时候，大家都会认为Sql语句中走Index Scan比Full Table Scan快，我前面也走进了这样的误区（对Index Scan的理解不够）。这两天重新复习了一下这方面内容，并整理了一下。
当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做出正确的估计而得出最佳的执行计划。
=======================
上面文中的“每读取一条记录都需要读取一次数据块，这样极有可能出现对同一个Data Block读取多次的情况”是我表述有些问题。可以这样理解：
在走Index Scan的时候，实际上是按照Index的键值顺序来读取表中数据的，所以当Index的键值顺序和数据存放的物理顺序（也即是说并不是按依键值那样的顺序相邻的记录存放在同一个block上）的时候，就会出现回头重新读取以前已经读取并处理过的Block（目的只是为了取其中某一条或者几条记录）。因为Oracle在根据键值读取记录的时候当后一个键值指向的记录不在当前CR的block上面的时候，就会丢弃当前block，然后重新构建一个CR来取得该键值指向的记录。当继续处理后面的键值的时候又遇到某一个或者几个键值指向了前面已经读取过的block的时候，Oracle不得不重新读取该block来在此构建一个CR（这里就出现了重复读取）。
相关文章
转载请注明：爱开源 » 索引扫描还是全表扫描