Question

我有一个数据库表，用于存储文件的文件路径和修订号。

每个文件都有一个与之关联的修订号。
每个文件在任何给定时间都有大约10个修订版。
每天都会为每个文件创建新修订
每天都会删除每个文件的最旧版本。
大约有1亿个文件

请相信以上需要这样，这是我真正问题的缩小范例。

此表的良好聚簇索引是否为“修订号”，因为我总是删除彼此接近的所有修订版？然后我还要为每个文件每天添加相同版本的所有新版本。

Answer 1

根据Kimberly L. Tripp's Blog，聚集索引应为：

独特
窄
静态
不断增加

因此，让我们根据这些标准评估您提出的“修订号”。

独特 - 这取决于您对Ed Harper评论的回答。如果它本身并不是唯一的，那么看起来修订号+文件的组合就是。
狭窄 - 假设修改类似于整数，那么你就可以了。如果您需要转到版本号+文件以获得唯一性，并且如果该文件的ID是另一个整数，那么您仍然可以。
静态 - 听起来修改版一旦创建就永远不会改变，所以你在这里很好。
不断增加 - 我现在正在阅读这些内容，但我认为您的新版本可能是以这种方式创建的。

总之，根据修订号的唯一性，似乎修订号或修订号+文件ID对于聚簇索引来说是个不错的选择。

Answer 2

除了Joe Stefanelli的答案之外，我还要补充一下：

桌子是如何使用的？
它只是一个转储或活动日志，它是用于OLTP目的（一次查找几行），它是否用于类似OLAP的活动（一次读取多个行）？
性能至关重要（必须以微秒时间检索行）或次要（例如是否为结束日报告）？

由于您只获得一个聚簇索引，因此我将根据这些答案定制聚簇索引，以便最好地支持系统要求。一些想法：

如果它是一个很少查询的日常日志，那么仅在RevisionNumber上的聚簇索引就足够了。

如果您报告在给定日期加载的所有文件，则RevisionNumber上的聚集索引将是理想的。

如果您需要以任何频率或权宜之计查找个人文件，那么该索引会很糟糕，因为如果我说得对，那么就会有100,000,000行（文件）每个RevisionNumber - 但FileName上的一个简单的非聚集索引，或FileName + RevisionNumber，将覆盖它（但请参阅下一个想法）。

对于快速查找，FileName，FilePath或FilePath + FileName可能是令人痛苦的长字符串索引。为校验和（FileWhatever）添加列（或持久计算列）并对其进行索引可以节省大量时间。查询必须看起来像：

SELECT FullFileName, Plus, Other, Columns
 from FileTable
 where RevisionNumber = @TargetRevision
  and ChecksumColumn = checksum(@TargetFullFileName)
  and FullFileName = @TargetFullFileName

最后，如果你真的每天都要添加和大约100,000,000行，我会认真研究表分区，分区基于RevisionNumber。

这是ms sql 2008的聚集索引的好地方吗？

2 个答案: