----轉載

其實這個概念很好理解，只是感覺當時理解了，過了段時間又模糊了，所以今天整理了下，

稍加深入思考：)

功力有限，有錯漏的地方還請大家指正。

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當然不會採用索引掃描，而是採用全表掃描，畢竟處理起來更加的塊，相

應的邏輯讀也會降低很多。

聚簇因子的理解

相關文章