【问题标题】:SQL Db index recommendationSQL Db 索引推荐
【发布时间】:2010-11-17 08:32:36
【问题描述】:

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

[编辑:我们使用的是 MS SQL Server 2008 R2]

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

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

我们将 NHibernate 与 Guid.Comb 一起使用,以避免使用普通的 bigint ID 进行索引查找。与普通 GUID 相比,这应该会减少碎片,但对于如此多的插入,碎片很快就会发生。

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

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

【问题讨论】:

  • 如何衡量“碎片化”?哪个数据库?
  • @Unreason:通过查询sys.dm_db_index_physical_stats。在 SSMS 中还有一种快速检查碎片的方法:右键单击任何索引,属性 --> 碎片。

标签: sql nhibernate fragmentation


【解决方案1】:

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

另外,也许你的碎片不是索引值的顺序和它们添加的顺序之间的差异的结果,而是自然的文件增长效应(如here解释)?

【讨论】:

    【解决方案2】:

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

    您可以尝试将主键设置为时间戳列和设备 ID 列的组合。您可以尝试将其设为集群。这应该可以让你尽可能快地写作。但是,如果您按设备查询,您可能需要另一个关于设备 ID 和时间戳的索引(反之亦然)。不过,我不会将聚集的相反,因为这将使写入发生在整个表上,而不是在尾随页面上。如果大多数查询涉及一个日期范围和多个设备,那么首先按时间戳进行集群应该可以为您提供最佳性能。

    【讨论】:

      猜你喜欢
      • 2017-06-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-04-19
      • 1970-01-01
      • 2012-12-19
      • 1970-01-01
      • 2012-04-17
      相关资源
      最近更新 更多