今天和一个朋友一起给一个组合分区重建索引,原因是集群因子比表的数据行还要多,到底集群因子高低,对性能有没有影响暂且不说,在操作中发现重建索引后,使用
Analyze table ticapp001.TTCGTR010 PARTITION ("PTCGTR0100_20101206" ) compute statistics;
Analyze table ticapp001.TTCGTR010 SUBPARTITION ("PTCGTR0100_20101206_BJS" ) compute statistics;
分析后,集群因子并没有变化,google后才发现,在对分区表进行分析时,是要是用dbms_stats，即
exec dbms_stats.GATHER_TABLE_STATS('TICAPP001','TTCGTR010',ESTIMATE_PERCENT=>dbms_stats.auto_sample_size,CASCADE=>TRUE);
对于使用哪个去收集statistics﹐有一个原则﹐凡是与cost-based optimizer相关的statistics﹐都应通过dbms_stats包收集。与cost-based optimizer无关的statistics(如empty blocks﹐average space等)都应通过analyze语句去收集。
之所以要用dbms_stats包去替代analyze收集优化器statistics﹐是因为dbms_stats包能收集并行statistics和分区对象的全局statistics。

生产环境下集群因子很高,请问相公,这样正常么?有没有隐患呢？

多谢高手指点！

    要保证表在存储时的顺序和索引的顺序尽量一致，LZ可以重建表，通过CTAS的方式，并且在将表时保证表是有序的（即加上ORDER BY子句）使他和索引的顺序一致。在以后的数据插入过程中尽量保证插入的数据是按序插入的，序列是一种解决方式但是有限制除非字段可以用序列来表达，如果列是其他类型的就需要借助其他方式了，此外还要注意尽量减少大量的delete、update等操作，即尽量减少频繁修改和索引相关的那几个字段的数据，否则久而久之表的集群因子还是会变的越来越大；
    集群因子会影响到ORACLE的执行计划，可能会导致本该走索引的地方却使用全表扫描，所以我们要尽量保证它的高效性；

有道理,请问该如何保证表在存储时的顺序和索引的顺序尽量一致呢?
通过在主键上使用序列这种方法可以保证么?

集群因子高的根本原因是表中数据行的顺序和索引的顺序相差很大（可以这么理解），所以如果集群因子很大通过rebuild index以及收集表的统计信息不会有很大改善，只有尽量使得表存储时的顺序和索引保持一致才能使得集群因子有一个很大的改善。