聚集指数？

Question

我有一个logtable（例如缩写）这些列：

user | time | uniqueid | msg

上有一个主键

user,time,uniqueid

和

上的聚集索引

user

现在用这个表完成的唯一三件事是：

• 插入条目
• 删除所有早于x
的条目
• 为用户选择条目（一次最多1k）

选择很少发生，插入一直发生，删除是每晚一次。

如果我理解正确，聚集索引将使选择非常快。 由于数据量的原因，我注意到删除会花费很长时间，而且我认为由于聚簇索引，情况会更糟。它是否正确？它也可能使插入物变得更慢（但数字一次很小，所以这可能不会那么容易被注意到）

我的想法是：

• 将聚集索引设置为时间
• 因为主键从未真正使用过（没有任何参考此表或任何内容）是否有意义删除它并在用户上为选择创建另一个索引？

优化此功能的最佳方法是什么？

Answer 1

通常我会使用一个人工主键，但对于日志表，这似乎没有多大意义，除非你省略了处理单个日志记录的要求。在这种情况下，使用非clusted索引维护主键对我来说更有意义，列中包含您指定的顺序。将聚簇索引更改为准时而不是用户。用户选择可以使用主键定义的索引，虽然减慢了一些，但仍然应该合理快速，因为它们可以使用索引扫描而不是表扫描。由于用户是第一列，即使行不再是连续的，也应该相当快。按时生成聚簇索引将大大加快删除速度，并可能减少碎片。由于您仍然只维护两个索引，因此不应影响插入性能。事实上，它可能会有所改进，因为表的结构将更接近地反映数据的插入方式。

Answer 2

我的建议：

• 将聚集索引保留在用户上;这将产生良好的选择性能。为聚集索引添加时间可能也会提高选择性能，因为您可能选择最近的记录（时间），对吗？
• 您的删除速度很慢，因为您没有索引时间;按时创建新索引。
• 插入可能有点慢，但如果不经常发生，那么我就不会太担心了。

在使用高峰期间，您每小时看到多少个插页？选择？还有什么是uniqueid？它是GUID吗？

Answer 3

如果UniqueId真的是唯一的，顾名思义 - 将理想候选人作为主键，我认为！

至于群集密钥 - 我通常主张强烈遵循NUSE原则 - 狭隘，独特，静态，不断增加。这似乎最适合UniqueID最佳。所以这绝对是一种选择。如果你有很多非聚集索引，这通常是一个很大的问题 - 这里你没有，所以你可以在这种情况下选择不同的聚簇索引。

您似乎有两个主要操作：

• 按user
选择
• 根据time
删除

因此，这两者中的任何一个都是群集密钥的良好候选者。如果您将群集密钥保留在user上，则用户选择将很快 - 您需要time上的其他非群集索引才能加快删除速度。