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 回答