Oracle 聚合因子的理解

转自：http://www.itpub.net/thread-1597222-1-1.html

Cluster Factor:聚簇因子

体现数据的离散程序(相对索引键而言)。

 

这个指标反应了被索引段是否按照索引键值密集的存储在一起，值越小，则

索引使用效率越高。

 

现实举例：我们知道，我们小时候查的字典也有索引，分为拼音索引和部首索引(其实还有一种

想不起来了)，拼音索引的效率最高，聚簇因子最小，因为字典的内容就是按照拼音来顺序存储的，

比如：当我们要查找与“啊”字同音的字时，只要先在索引中找到"啊"第一声，与"啊"第二声所对应的

页（在数据库中就对应块号了），则我们就可以直接翻到这"几页"进行查询了。

 

而另外一方面，假如我们查询有"匚"部首的字时，我们知道，这些部首可能分布在字典中

的每页中。

针对部首的情况我们就要科幻一下场景了，假如现在你变身为超人，超人一般看书都是秒记

的:)，假如你设定自己一次可以看128页（db_file_multiblock_read_count）的字典内容（其

它功力用来做其它的事，一心多用嘛），那么在这种情况下，假如你查找有"匚"部首的字，你

还会去看索引吗？我想你肯定会去快速的翻看整个字典来连到自己的目的。

另外，索引读一般都是一块一块的读取(ffs除外)，这坚定了超人的选择（超人做事图的就是个霸气），而实际中的超人就是CBO所使用的基础资源。

 

数据库层举例：表tab列col拥有索引，我们知道索引是排序过的段，所以如果表段中数据

行按照索引键顺序存储，则这个索引的聚簇因子就很小，此时称索引段键值顺序与表段列

顺序成平行状态，索引工作效率最高，被使用情况最大。

 

索引段 表段

A------- A des1

A des2

B------- B des4

B des9

C------- C des10

 

而对于聚簇因子很大的情况下，上图中就呈现出交叉状态，而非平行状态了。

 

针对上图再做个思考：在数据段值相对与索引键值很散的情况下，假如我们做如下谓词筛选

where col between 'A' and 'B'，则在查A(A所在索引块为block 8)所对应的表记录时，Ora

cle可能遍历过占整个表段的38%的数据块，而当查询B(B所有索引块为block 9)所对应的表记

录时，Oracle可能又遍历了查询A时所遍历的80%的buffer块(只能说B相对与A更散)，而此时

实际的扫描块占表段大概是0.35+0.35*0.8=0.63，而其实整个返回的行可能只占整个记录的

20%，但是此时CBO当然不会采用索引扫描，而是采用全表扫描，毕竟处理起来更加的块，相

应的逻辑读也会降低很多。