1

我在 SQL Server 数据库中有一个相当独特的表，它不遵循“典型”使用约定，并且正在寻找有关聚簇索引的一些建议。

这是一个虚构的例子，但非常接近真实数据。

该表有一个 3 列的主键，它们实际上是其他表的外键，以及包含相关数据的第四个字段。对于此示例，假设表如下所示：

CREATE TABLE [dbo].[WordCountsForPage](
 [AuthorID] [int] NOT NULL,
 [BookID] [int] NOT NULL,
 [PageNumber] [int] NOT NULL,
 [WordCount] [int] NOT NULL
)

所以，我们有一个有点分层的主键，唯一的数据是第四个字段。

在实际应用中，总共有 28 亿条可能的记录，但仅此而已。这些记录是随着时间的推移计算数据而动态创建的，实际上可能只有 1/4 的记录会被实际计算。它们存储在数据库中，因为计算是一项昂贵的操作，我们只想为每个唯一组合执行一次。

今天，数据每分钟被读取数千次，但是（至少目前）随着表自身的填充，每分钟也有数百次插入（这将持续相当长的一段时间）。我会说每个插入（今天）有 10 次读取。

我想知道我们是否因为聚集索引而对所有这些插入进行了性能打击。

聚集索引“长期”是有意义的，因为该表最终将变为只读，但需要一些时间才能到达那里。

我想我可以在繁重的插入期间使索引不聚集，并在表填充时将其更改为聚集，但是您如何确定交叉点何时会出现（以及将来如何通知自己'时间到了'）？

我真正需要的是一个可转换的索引，它可以在未来某个神奇的时刻从非聚集变为聚集。

关于如何处理这个问题的任何建议？

4

1 回答 1

3

实际上，我不会费心先尝试拥有一个非聚集索引，然后再将其转换为聚集索引（仅此一项就非常麻烦！）。

正如索引女王 Kimberly Tripp 在她的 The Clustered Index Debate Continues中解释的那样，在表上使用聚集索引实际上可以提高您的 INSERT 性能！

与堆相比，在聚簇表（但仅在“正确”聚簇表中）中的插入速度更快。这里的主要问题是，在 IAM/PFS 中查找以确定堆中的插入位置比在聚集表中（插入位置已知，由聚集键定义）中的查找要慢。当插入到定义了顺序 (CL) 并且该顺序不断增加的表中时，插入会更快。

堆是一个没有定义聚集索引的表。

考虑到这一点，以及从堆到具有聚集索引的表所需的努力和麻烦——我什至不会打扰。只需定义您的索引，然后开始使用该表！

于 2010-12-04T08:51:34.247 回答