在SQL Server中更改日期列的聚集索引性能问题

我们正在使用SQL Server 2008 Enterprise版本。我们有一个大表FooTable（数十亿行）。在SQL Server中更改日期列的聚集索引性能问题

FooTable列：site:varchar(7), device:varchar(7), time(datetime), value(float)

我们每天都插入数以百万计的新行。

我们为site,device和time（按顺序）创建了聚簇索引。

正如我们所见，site和device是相对恒定的，但time将随着时间的推移而不断变化。

对这个表执行的查询将是：

INSERT INTO FooTable SELECT * FROM #BULK_INSERTED_TEMP_TABLE
SELECT value FROM FooTable WHERE site = 'fooSite' AND device = 'fooDevice' AND time = 'fooTime'
SELECT SUM(value) FROM FooTable WHERE site = 'fooSite' AND device = 'fooDevice' AND time > 'startTime' AND time <= 'endTime'

什么是最好的聚集索引设计？

2012-02-24 unruledboy

不可能肯定地说不知道访问表的查询。 'site，device，time'将导致碎片化。 – 2012-02-24 11:50:20

你能告诉我们**表结构**（数据类型很重要!!不只是列名.....）另外：什么样的**查询**所以你期望在这张表上？你有什么样的其他指数（非集群指数） - 以及有多少？ – 2012-02-24 13:11:24

+1。还有什么软件？ Enterpise版本？你可能希望使用一个按照site ...羚牛的索引分区表;）但是，需要企业版才能使用partitioend表。 – TomTom 2012-02-24 13:12:35

最好的聚集索引设计没有人真正的答案。一般来说，我从两种方式看聚集索引。首先，他们存储数据，因此您需要从数据存储方面考虑这些数据。您是否正在创建一个可能会在新数据到达时不断分裂页面的群集？其次，因为它们存储数据，所以应该考虑将最常用的查询来检索数据。这些查询是否能够使用聚集索引来获取数据？

对于你的设置几乎一无所知，你有聚集索引的最佳选择吗？我会说可能不会。你定义的是一个有效的主键候选者，但是你已经概述的结构，两列将把数据分组到一个特定的结构中，并与不断增加的数据结合在一起，在前两栏的分布范围内的位置表明你将会看到很多页面拆分。这可能是也可能不是问题，但这是你需要监控的事情。

2012-02-24 11:54:15

我主要关注表现，虽然空间也应该考虑，但相对不如表现重要。由于这3列包含了99％的日常使用量，所以我们必须一起使用它们。但是对于片段，页面拆分，新记录到达时的排序，它们可能会造成性能下降 – unruledboy 2012-02-24 20:37:22

空间不在我的考虑范围之内。是的，碎片化索引会增加空间，但这是性能问题，这是更大的问题。不知道你的数据，我不能告诉你这个命中会有多大，但这是我在评估中关注的东西。 – 2012-02-25 11:52:06

根据你添加的查询，是的，可能这也是我使用的集群密钥，但同样，你可能正在寻找大量的页面拆分。另一个性能问题是重新排列页面的行为，当您测试设计时需要监视其他内容。 – 2012-02-25 11:53:29

回答