让我们假设你有三列一个巨大的表,如下图所示:SQL Server - 分区表与集群索引?
[id] INT NOT NULL,
[date] SMALLDATETIME NOT NULL,
[sales] FLOAT NULL
还假定您仅限于一个物理磁盘和一个文件组(主)。您预计此表在100个日期(容易1B +记录)中保持10,000,000个ID以上的销售额。与许多数据仓库场景一样,数据通常会按日期顺序增长(即,每次执行数据加载时,您将插入新日期,并且可能会更新某些更新的数据日期)。出于分析目的,数据通常会被随机查询并汇总到〜10,000个id,这些id将通过与另一个表的联接来指定。通常,这些查询不指定日期范围,或者指定非常宽的日期范围,这引起我的问题:索引/分区此表的最佳方法是什么?
我已经想了一段时间,但是卡具有冲突的解决方案:
选项#1:随着数据将依次被日期被加载,定义群集索引(和主键)作为[日期],[id]。还可以在日期上创建“滑动窗口”分区功能/方案,以便将新数据快速移入/移出表格。有可能在ID上创建非聚集索引以帮助查询。
预期的结果#1:这种设置会非常快的数据加载的目的,但次优的,当涉及到分析原文,在最坏的情况下(不受日期限制,不吉利与集ID的的查询),可以读取100%的数据页面。
选项2:由于数据一次只能查询一小部分ids,因此将聚集索引(和主键)定义为[id],[date]。不要打扰创建分区表。
预期结果#2:由于我们无法再按日期快速限制,因此在加载数据时预期会有巨大的表现。当涉及到我的分析查询时,预计会带来巨大的性能收益,因为它可以最大限度地减少读取的数据页的数量。
选项#3:集群(和主键)如下:[id],[date]; “滑动窗口”分区功能/方案日期。
预期结果#3:不知道该期待什么。考虑到聚集索引中的第一列是[id],因此(这是我的理解)数据是按ID排列的,我希望我的分析查询具有良好的性能。但是,数据按日期进行分区,这与聚簇索引的定义相反(但仍与日期成为索引的一部分对齐)。我还没有找到很多说明这种情况的文档以及我可能从中获得哪些性能优势,这会带来我最终的奖金问题:
如果我在一个文件组上创建表一个磁盘,在一列上有一个聚簇索引,在同一列上定义一个分区会带来什么好处(加载数据时除了分区切换)?
你最后一点很有趣。从float转换为numeric会带来什么样的性能好处? – 2008-09-23 13:42:40
您可以更准确地了解您正在存储的数据,并且数字数据类型是精确数字,其中浮点数是近似数字。 – GateKiller 2008-09-23 18:04:46