聚簇因子

        堆表的最大特征是数据的存储独立性，即数据的存储与数据值没有任何关联地被存储在磁盘的任意位置上。从另外一个侧面来看，该特征也就意味着为查询我们所需要的数据必然要在磁盘的多个位置上进行查找。从这个结论上讲，如果查询的结果为100条记录，这100条记录分布在1个数据块上与分布在100个数据块上相比，肯定是前者的效率更高。

 

   所谓“任意位置”的深层含义是指能够把数据物理地存储在磁盘上的方法多种多样。这就是我们前面所介绍的随机存储方式，即允许数据存储在磁盘的任意位置上。然而，从另外一个角度来看，随机存储方式就是数据所占据的位置分散在不同的数据块上。

 

   尽管在不同系统环境下会略有一些差异，但在一般情况下，从内存块上查询数据的速度比从磁盘块上查询数据的速度快30倍左右。由于数据被分散地存储在多个数据块上，数据读取效率也同样会随着它们的分散程度不同而不同。即分散程度越高，数据读取效率越低；分散程度越低，数据读取效率越高。换言之，数据被存储得越集中，数据读取效率越高；数据被存储得越分散，数据读取效率越低下。

 

   我们知道，由于数据的物理存储方式是数据存储时决定的，且物理存储方式只能按照一种顺序存储数据，所以顺序一旦被决定就不能根据读取条件而随心所欲地改变。因此，不论我们采用何种存储方式来存储数据，最终都会使得每一个列值的存储集中程度与其他列值的存储集中程度之间出现一定的差异（也就是表中各个列值的存储集中程度相互之间存在着一定的差异）。例如，即是同父同母的兄弟姐妹，他们与父母的相像程度也存在一定的差异。

 

   聚簇因子是指，按照索引列值进行了排序的索引行序和对应表中数据行序的相似程度。这就好似把孩子与父母的想像程度用数值来表示一样。由于聚簇因子大小对数据读取效率有着直接的影响，所以在后面将要说明的所有表类型中都会对聚簇因子显得格外重要。

 

  事实上，提高聚簇因子的有效方法有很多，但这些方法的不足之处就在于数据存储时需要付出的代价较大。在提高聚簇因子方面显得最无效的就是堆表，因为这种表结构所采用的并不是对数据的存储具有强制性约束的固定存储方式，而是按照数据插入的顺序进行存储的随机存储方式。

 如果通过少量额外代价就可以按我们期望的方式来提高聚簇因子，则也算是实现以较小代价换取较高读取效率的目的。这里所谓的“期望的方式”是指按照特定的方法存储数据的方式。

                                                                                                          

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

数据库层举例：表tab列col拥有索引，我们知道索引是排序过的段，所以如果表段中数据
行按照索引键顺序存储，则这个索引的聚簇因子就很小，此时称索引段键值顺序与表段列
顺序成平行状态，索引工作效率最高，被使用情况最大。

 

浙江移动日志分析系统在这方面设计真的挺好，考虑到聚簇因子。表是分区表（堆表），数据是按照timeid(时间)顺序加载到数据库中的，创建索引在timeid（时间）和msdsn(手机号码)上。这时，数据分布比较集中，这个聚簇因子还是比较小，查询速率也相对比较高。

所以在数据仓库中，不宜做update等dml操作。也需要考虑聚簇因子。

 

列个举例：

 

select * from  DT_VS_PO_VEHICLES where  po_no='VP1202042442'  and company_id=2046and po_row_id=1;

 

在表tmp_DT_VS_PO_VEHICLES创建了组合索引的字段(po_no, company_id, po_row_id).索引可以这么认为由键值（索引字段上的值）与rowid(rowid可以认为是一个指针，它是唯一的，指向表中的数据行)组成。当根据键值查出来的数据也就是rowid非常集中的存放在数据块中时，此时聚簇因子就比较小，执行的效率也就提高了。