SQL Db索引建议

时间:2010-11-17 08:32:36

标签: sql nhibernate fragmentation

我正在尝试查看是否为特定类型的数据使用自定义索引可能会减少数据库中的碎片。

[编辑:我们正在使用MS SQL Server 2008 R2]

我有一个包含带时间戳的测量数据的SQL数据库。一直插入大量数据,但一旦插入,几乎不需要更新。但是,这些时间戳唯一,因为多个设备(大约50个)同时测量数据。

这意味着表中的每50行包含相等的时间戳值。这些数据或多或少同时接收,尽管我可以更加小心地确保尽可能顺序地写入行(如果这会有所帮助),可能是将它们保留在内存中一段时间​​然后只有在我获取数据时写入来自所有设备的单个时间戳。

我们正在使用NHibernate和Guid.Comb来避免使用普通的bigint ID进行索引查找。与简单的GUID相反,这应该可以减少碎片,但是对于如此多的插入,碎片很快就会发生。

由于我的数据带有时间戳,并且几乎按顺序插入数据(增加时间戳),我想知道是否有更聪明的方法来为此表创建具有唯一聚簇索引的主键。 Timestamp列基本上是一个bigint数字(.NET DateTime ticks)。

我还注意到,同一时间戳列上的非聚集索引也会变得非常碎片化。那么在这种情况下,您建议采用什么样的索引策略来减少堆碎片?

2 个答案:

答案 0 :(得分:2)

也许看看这个answer,HiLo看起来很有趣。

此外,您的碎片可能不是由于索引值的排序与添加顺序之间的差异造成的,而是自然文件增长效应(如here所述)?

答案 1 :(得分:1)

键的单独列对此表没有多大意义,因为您不会更新任何数据。我想你可能会做很多查询,可能是基于那个时间戳列。

您可以尝试将主键设置为timestamp列和设备ID列的组合。您可以尝试制作群集。这应该让你几乎尽可能快地写。但是,如果按设备查询,则可能需要设备ID和时间戳的另一个索引(反向)。我不会反过来使用聚簇,因为这会使写入遍及表而不是尾随页。如果大多数查询涉及日期范围和多个设备,则首先在时间戳上进行聚类可以为您提供最佳性能。