在日志记录表上的不断增加的日期时间列上聚集索引？

Question

我不是DBA("好!",你马上就会思考.)

我有一个记录数据表,其中包含以下特征和使用模式:

• 一个datetime用于存储日志时间戳,其值列是不断增加的,大部分(但大多只)唯一
• Frequent-ish插入(例如,每分钟十几次),仅在时间戳范围的末尾(记录新数据)
• 从时间戳范围的开头大量删除(旧数据被清除)
• 根本没有更新
• Frequent-ish选择使用timestamp列作为主要标准,以及其他列的次要标准
• 不经常选择使用其他列作为条件(不包括时间戳列)
• 大量的数据,但远远不够,我担心存储空间

此外,目前还有一个日常维护窗口,在此期间我可以进行表格优化.

坦率地说,即使我对它进行了错误索引,我也不希望这个表挑战它将要启动的服务器,但是它似乎是一个很好的机会,可以在SQL Server聚簇索引上请求一些输入.

我知道聚簇索引确定实际表数据的存储(数据存储在索引本身的叶节点中),非聚簇索引是指向数据的单独指针.因此,在查询术语中,聚簇索引将比非聚集索引更快 - 一旦我们找到了索引值,数据就在那里.插入和删除都有成本(当然,更新聚簇索引列的值的更新将特别昂贵).

但我在这个答案中读到,除非重建索引,否则删除不会被清理的空隙.

所有这些都告诉我,我应该:

• 在具有100%填充因子的时间戳列上放置聚簇索引
• 将非聚集索引放在任何其他列上,该列可用作不涉及聚簇列的查询中的条件(在我的情况下可能是其中任何一个)
• 安排在每日维护间隔期间发生批量删除
• 安排在批量删除后立即重建聚集索引
• 放松,多出去

我在那里疯狂吗？我是否需要经常重建索引以避免浪费大量空间？还有其他明显的(对于DBA)我应该做的事情吗？

提前致谢.

Answer 1

与许多人认为的相反,在表上拥有良好的聚簇索引实际上可以使INSERT之类的操作更快 - 是的,更快!

查看开创性的博客文章The Clustered Index Debate Continues ....作者:Kimberly Tripp--终极索引女王.

她提到(大约在文章的中间):

与堆相比,嵌入在集群表中更快(但仅在"右"聚簇表中).这里的主要问题是IAM/PFS中用于确定堆中插入位置的查找比群集表(其中插入位置已知,由群集键定义)慢.插入到定义了顺序(CL)的表中以及该顺序不断增加的位置时,插入更快.

关键点在于:只有使用正确的聚簇索引,您才能获得收益 - 当聚簇索引是唯一的,狭窄的,稳定的并且最佳地不断增加时.这最适合使用INT IDENTITY列.

Kimberly Tripp也有一篇很棒的文章,介绍如何为你的表格选择最好的聚类键,以及它应该达到的标准 - 请参阅她的帖子题为不断增加的聚类键 - 聚集索引辩论......... .再次!

如果您有这样一个列 - 例如代理主键 - 使用它作为您的群集键,您应该在表上看到非常好的性能 - 即使在很多INSERT上也是如此.

Answer 2

我同意将聚集索引放在时间戳列上。我的查询将针对填充因子 - 100% 提供最佳读取性能，但会牺牲写入性能。您可能会因页面拆分而受到伤害。选择较低的填充因子会延迟页面拆分，但会牺牲读取性能，因此这是一种很好的平衡行为，可以根据您的情况获得最佳效果。

批量删除后，值得重建索引并更新统计信息。这不仅可以保持性能提升，还可以将索引重置为指定的填充因子。

最后，是的，将非聚集索引放在其他适当的列上，但仅限于非常选择性的列，例如不是位字段。但请记住索引越多，对写入性能的影响就越大