sql-server-2005 - 我应该在此 SQL 2005 表上创建唯一聚集索引还是非唯一聚集索引？

Question

我有一个存储数百万行的表。它看起来像这样:

Table_Docs
ID, Bigint (Identity col)
OutputFileID, int
Sequence, int
…(many other fields)

我们发现设计它的开发人员将 OutputFileID 设置为聚集索引。它并不独特。具有此 ID 的记录可能有数千条。它对任何使用该表的进程没有任何好处，因此我们计划将其删除。

问题是，将其更改为什么...我有两个候选者，ID身份列是一个自然的选择。但是，我们有一个进程在此表上执行大量更新命令，并且它使用序列来执行此操作。该序列不是唯一的。大多数记录只包含一个，但大约 20% 可以有两个或多个具有相同序列的记录。

INSERT 应用程序是一个 VB6 碎片，向表中抛出数千个插入命令。插入的值从来不按任何特定顺序排列。所以一次插入的序列可能是12345，下一次插入可能是12245。我知道这可能会导致SQL移动大量数据以保持聚集索引有序。然而，插入的顺序通常接近有序。所有插入都将发生在聚簇表的末尾。例如:我有 500 万条记录，序列范围为 1 到 500 万。 INSERT 应用程序将在任何给定时间在该范围的末尾插入序列。数据的重新排序应该最少(最多数万条记录)。

现在，UPDATE 应用程序是我们的 .NET 明星。它对序列列执行所有更新。 “Update Table_Docs Set Feild1=This, Field2=That...WHERE Sequence =12345” – 每天数十万个。更新是完全随机的，涉及表的所有点。

所有其他进程都只是在此(网页)上执行 SELECT。常规索引涵盖了这些内容。

所以我的问题是，哪个更好......ID 列上的唯一聚集索引有利于 INSERT 应用程序，或者 Sequence 上的非唯一聚集索引有利于 UPDATE 应用程序？

Answer 1

首先，我绝对建议使用聚集索引!

其次，您的聚集索引 should be :

• 窄
• 静态(从不或几乎从不改变)
• 独特
• 不断增加

所以 INT IDENTITY 是一个经过深思熟虑的选择。

当您的聚集键不唯一时，SQL Server 将为这些列值添加一个 4 字节的唯一符 - 从而使您的聚集键以及该表上的所有非聚集索引变得更大且不太理想。

所以在你的例子中，我会选择 ID - 它是狭窄的、静态的、唯一的并且不断增加的 - 没有比这更优化的了!由于Sequence在UPDATE语句中被大量使用，所以一定要在它上面放置一个非聚集索引!

参见 Kimberly Tripp 的精彩文章 blog posts on choosing the right clustering key有关该主题的精彩背景信息。