(转)索引扫描还是全表扫描（Index Scan Or Full Table Scan）

作者：Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明
链接：http://www.jianzhaoyang.com/database/index_scan_or_full_table_scan

在大多数时候，大家都会认为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，每读取一条记录都需要读取一次数据块（这里表述有点问题，已经在下面的comments中解释），这样极有可能出现对同一个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做出正确的估计而得出最佳的执行计划。