SQL Server：按时间戳进行聚类；优点/缺点

Question

我在 SQL Server 中有一个表，我希望将插入添加到表的末尾（而不是使用会导致它们插入到中间的聚集键）。这意味着我希望表由一些不断增加的列聚集。

这可以通过在 datetime 列上进行聚类来实现：

CREATE TABLE Things (
    ...
    CreatedDate datetime DEFAULT getdate(),
    [timestamp] timestamp,        

    CONSTRAINT [IX_Things] UNIQUE CLUSTERED (CreatedDate)
)

但我不能保证两个 Things 不会有相同的时间。所以我的要求并不能真正通过日期时间列来实现。

我可以添加一个虚拟身份< /strong> int 列，并对其进行聚类：

CREATE TABLE Things (
    ...
    RowID int IDENTITY(1,1),
    [timestamp] timestamp,        

    CONSTRAINT [IX_Things] UNIQUE CLUSTERED (RowID)
)

但是您会注意到我的表已经包含 时间戳列；保证单调递增的列。这正是我想要的候选簇键的特征。

因此，我将表聚集在 rowversion （又名 timestamp）列上：

CREATE TABLE Things (
    ...
    [timestamp] timestamp,        

    CONSTRAINT [IX_Things] UNIQUE CLUSTERED (timestamp)
)

而不是添加虚拟 identity int 列(RowID) 为了确保顺序，我使用已有的。

我正在寻找的是为什么这是一个坏主意的想法；以及还有哪些更好的想法。

注意：社区 wiki，因为答案是主观的。

Answer 1

所以我将表聚集在
rowversion（又名时间戳）列：
而不是添加一个虚拟身份
int 列（RowID）以确保顺序，
我使用已有的东西。

乍一看，这可能听起来是个好主意 - 但这实际上几乎是您拥有的最糟糕的选择。为什么？

聚集键的主要要求是（请参阅 Kim Tripp 的博客文章 了解更多精彩详细信息）：

• 如果可能，稳定
• 狭窄
• 唯一
• 不断增加

您的 rowversion 违反了稳定要求，这可能是最重要的要求。行的行版本随着对行的每次修改而变化 - 并且由于您的聚集键被添加到表中的每个非聚集索引，因此您的服务器将不断更新非聚集索引的负载并浪费大量时间这样做。

最后，添加一个虚拟身份列对于您的情况可能是一个更好的替代方案。第二个最佳选择是 datetime 列 - 但在这里，您确实面临 SQL Server 在出现重复项时必须向您的条目添加“唯一符”的风险 - 并且精度为 3.33 毫秒，这可能肯定会发生 - 不是最佳的，但绝对比 rowversion 的想法好得多......

Answer 2

来自链接：时间戳问题：

时间戳语法已弃用。
此功能将在
Microsoft SQL 的未来版本
服务器。避免在以下情况中使用此功能
新的开发工作，并计划
修改当前使用的应用程序
此功能。

和

重复的 rowversion 值可能是
使用 SELECT INTO 生成
语句，其中 rowversion 列
位于 SELECT 列表中。我们不
建议在此使用 rowversion
方式。

那么到底为什么要按其中任何一个进行聚类，特别是当行更新时它们的值 alwsys 会发生变化？只需使用一个身份作为 PK 并对其进行集群即可。

Answer 3

你已经走在正确的轨道上了。您可以使用保存创建日期的 DateTime 列并创建聚集但非唯一约束。

CREATE TABLE Things (
    ...
    CreatedDate datetime DEFAULT getdate(),
    [timestamp] timestamp,        
)

CREATE CLUSTERED INDEX [IX_CreatedDate] ON .[Things] 
(
    [CreatedDate] ASC
)

Answer 4

如果该表进行大量插入，您可能会创建一个干扰更新的热点，因为所有插入都将发生在相同的物理/索引页上。检查您的锁定设置。