我在 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 次读取。
我想知道我们是否因为聚集索引而对所有这些插入进行了性能打击。
聚集索引“长期”是有意义的,因为该表最终将变为只读,但需要一些时间才能到达那里。
我想我可以在繁重的插入期间使索引不聚集,并在表填充时将其更改为聚集,但是您如何确定交叉点何时会出现(以及将来如何通知自己'时间到了')?
我真正需要的是一个可转换的索引,它可以在未来某个神奇的时刻从非聚集变为聚集。
关于如何处理这个问题的任何建议?