clustering_factor如何保证较小

bisal

clustering_factor反映了索引值的排列顺序和表数据排列顺序之间的一致性，该值越小，运用到索引的查询/更新/删除语句使用索引的效率越高，否则很可能CBO建议使用全表扫描。
但要求有较低的clustering_factor，则必须保证表数据的插入顺序和索引插入顺序一致，这点可能对于不同的场景，难度不同，例如一个表中有多个索引，很可能为了保证这个索引的排列顺序和表数据插入排列顺序一致，则另外一个索引的clustering_factor就很高，很难均衡。
对于这种情况，请教下有什么好的建议么？或者说这种为了保证clustering_factor较低需要应用做什么配合比较合适呢？谢谢。

www_xylove

重建表，然后，
再重建索引

ZALBB

鱼和熊掌不可兼得，应该考虑其他优化手段，

lfree

你能做的最多是不要使用assm，这样不是密集插入的表也许能获得好的cf。

ZALBB

lfree 发表于 2015-2-23 11:59
你能做的最多是不要使用assm，这样不是密集插入的表也许能获得好的cf。

assm  方式与密集插入，对cf有什么影响？

lfree

ZALBB 发表于 2015-2-24 11:01
assm  方式与密集插入，对cf有什么影响？

assm 会使各个会话插入到不同的块,这样比如一些线性增加的字段,比如序号以及像日期这样的字段相邻的不在同一块中,人为导致cf偏高,而实际上这些字段的本质讲cf不应该很高

讲一个简单的例子加入插入后:
块1: 1,3,5,7,9
块2: 2,4,6,8,10
这样cf是10.

而如果你把这两块看成1个整体 ,cf=1

日复一日王

重建表 create table  order by col1；
再建索引；
完事儿！
聚簇因子对索引范围扫的影响比较大，其余的索引扫意义不大。

bfc99

日复一日王 发表于 2015-3-12 16:05
重建表 create table  order by col1；
再建索引；
完事儿！

如果表上只有一个索引可以，如果有多个，那就是按下了葫芦起了瓢。这个索引合适了，另一个索引就会差。

htyro

兼顾最主要的索引即可，不同的索引列排序都不一样，基本上很难做到所有的索引了的C_F都很小，具体根据业务场景来取舍吧。

日复一日王

bfc99 发表于 2015-3-12 17:42
如果表上只有一个索引可以，如果有多个，那就是按下了葫芦起了瓢。这个索引合适了，另一个索引就会差。

难不成你这些索引都是范围扫的吗？只针对范围扫的索引做这个操作。如果有2个以上索引做范围扫，以涉及数据最多的范围扫为准。