声明:本文为转载,如果有侵犯知识版权，请通知本人，本人将即刻停止侵权行为:
转载网址：http://www.dbasupport.com/forums/archive/index.php/t-38893.html
Introduction
The index custering factor is a key statistic that can improve both the Oracle optimizer's performance, and the technician's understanding of the utility of an index.
index Clustering factor是提高Oracle优化性能的关键的统计资料，决定是否使用索引。
It is used by Oracle's optimizer to help determine the cost associated with index range scans in comparison to full table scans.
优化器使用它来决定是使用索引扫描还是全表扫描。
Calculating the Clustering Factor
To calculate the clustering factor of an index during the gathering of index statistics, Oracle does the following.
For each entry in the index Oracle compares the entry's table rowid block with the block of the previous index entry. If the block is different, Oracle increments the clustering factor by 1.
对于每一个entry包含的表的rowid，oracle和之前的索引块进行对比，如果数据块是不同的，那么cluster factor数值+1
The minimum possible clustering factor is equal to the number of blocks identified through the index's list of rowid's -- for an index on a column or columns conatining no nulls, this will be equal to the number of blocks in the table that contain data. The maximum clustering factor is the number of entries in the index.
最小的cluster factor的值，等于通过所以识别的数据块的个数-针对索引列和不含有空值的列，聚集因子将等于表中包含数据的数据块个数。
最大的cluster factor的值，等于在索引中的entry的个数，也就是表中的行数。
Interpreting the Clustering Factor
So this means that Oracle now has a statistic to allow it to estimate how many table blocks would be associated with an index range scan.
If the clustering factor is close to the number of entries in the index, then an index range scan of 1000 index entries may require nearly 1000 blocks to be read from the table.
如果聚集因子的值接近与索引中的ertry的数量（表的行数），那么针对1000个entry的索引范围扫描，需要从表中读取1000个数据块。
If the clustering factor is close to the number of blocks in the table, then an index range scan of 1000 index entries may require only 50 blocks to be read from the table.
如果聚集因子的值接近表中的数据块的个数，么针对1000个entry的索引范围扫描，可能仅仅需要从表中读取50个数据块。
This can be compared with the cost of reading the entire table up to the high-water mark (using the more efficient multiblock i/o mechanism) to determine whether a full table scan or an index range scan offers the most efficient access mechanism.
它可以通过和至高水位线的全表读取（可以使用更高效的多块扫描）比较，它们直接的成本，来决定使用全表扫描还是索引范围扫描来提供更高效的访问机制。
Note that where extensive deletes have occurred from the table there may be blocks with no rows in. These will be accounted for in the clustering factor because those blocks will not appear in the index's rowid list. The full table scan will still read all table blocks up to the high water mark, regardless of whether they contain rows or not. So in an extreme case it is possible that Oracle could see from the index and table statistics that although a table has 1,000,000 blocks below the high water mark, reading 100% of the rows in the table might only require reading 10 of those blocks. Providing that "Not Null" constraints tell Oracle that all table rows are present in the index, a query such as "select * from big_table_with_few_rows" might be more efficiently satisfied with an index range scan than with a full table scan.
注意：对于经常删除大量的数据，这将会造成数据块不再存储数据（高水位线也不会下降），着再cluster factor是位于说明的，因为这些数据块不会出现在index 中的rowid中的列表中，但是，全表扫描会扫描在高水位线下的所有的数据块，而不管该数据块是否存在数据，在一些极端的例子下，oracle可能从索引和表的统计资料中，看到当前表有1000000个数据块在高水位线下，需要读取表中的全部行可能仅仅需要读取10个数据块。在表中对于索引列提供非空约束，类似于select * from big_table_with_few_rows，当使用索引扫描的效率可能会高于全表扫描是的效率。
Note also that calculating the clustering factor is done without reference to the table at all -- it is based solely on information contained in the index.