聚集索引？答案

【问题标题】：Clustered Index?聚集索引？
【发布时间】：2011-12-16 11:22:04
【问题描述】：

我有一个包含（例如缩短）这些列的日志表：

user | time | uniqueid | msg

还有一个主键

user,time,uniqueid

和

上的聚集索引

user

现在这张表只做三件事：

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

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

如果我理解正确，聚集索引将使选择非常快。由于数据量很大，我注意到删除将花费很长时间，而且我想这会因为聚集索引而变得更糟。它是否正确？此外，它还可能使插入速度变慢（但数量很少，因此可能不会那么容易注意到）

我的想法是：

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

优化它的最佳方法是什么？

【问题讨论】：

标签： sql-server-2008-r2 clustered-index

【解决方案1】：

如果 UniqueId 真的是独一无二的，正如它的名字所暗示的那样 - 在我看来，那将是理想的候选作为主键！

至于集群键——我通常强烈主张遵循 NUSE 原则——窄、唯一、静态、不断增长。这似乎最适合UniqueID，在这里。所以这绝对是一种选择。如果您也有很多非聚集索引，这通常是一个大问题 - 您在这里没有，所以在这种情况下您可能会选择不同的聚集索引。

你似乎有两个主要的操作：

选择user
删除基于time

因此，这两者中的任何一个都将是聚类键的良好候选者。如果您将集群键保留在 user 上，那么用户选择会很快 - 您需要在 time 上添加一个额外的非集群索引来加快删除速度。

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

我的建议：

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

在高峰使用期间，您每小时看到多少次插入？选择？另外，什么是uniqueid？它是 GUID 吗？

【讨论】：

如上所述 .. 选择很少发生（可能每天最多 20 次或更少），所以这并不重要。如果它需要两倍的时间 - 就这样吧。插入一直发生，取决于客户可能高达每秒 10-20 次。即使是少量的批准也会产生很大的不同。
由于插入如此频繁，我将在该列上添加一个新列，即 int、identity 和主键和集群；这应该会产生最好的插入结果（没有页面拆分）并最大限度地减少空间/内存使用。我会做两个索引：时间和用户+时间。