sql-server – 在日志表上不断增加的datetime列集群索引？

我不是DBA(“好！”,你会在一会儿想.)

我有一个具有这些特征和使用模式的日志记录表：

>一个datetime列,用于存储日志时间戳,其值越来越大,但主要(但是大部分)是唯一的
>频繁插入(例如,十几分钟),只在时间戳范围(新数据被记录)的末尾
>从时间戳范围开始(旧数据被清除)批量删除,
>根本没有更新
> Frequent-ish选择使用timestamp列作为主要标准,以及其他列的辅助条件
>不频繁地选择使用其他列作为标准(不包括时间戳列)
>数据量很大,但无处可以接近我对存储空间的担忧

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

我坦白的是,不要指望这个表来挑战服务器,即使我错误地索引了它,但是似乎是一个很好的机会,要求在sql Server集群索引上提供一些输入.

我知道聚簇索引确定实际表数据的存储(数据存储在索引本身的叶节点中),而非聚集索引是数据中的独立指针.所以在查询方面,聚集索引要比非聚集索引更快 – 一旦我们找到索引值,数据就在那里.插入和删除有成本(当然,更改聚簇索引列的值的更新将会特别昂贵).

但是我读了in this answer,删除留下的空白,除非重建索引,否则不会被清理.

所有这些都表明我应该：

>将带有100％填充因子的聚簇索引放在时间戳列上
>将非聚集索引放在可能用作查询中的标准的任何其他列上,该列也不涉及集群列(在我的情况下可能是其中的任何列)
>安排在日常维护间隔期间发生批量删除
>安排在批量删除后立即发生聚簇索引的重建
放松和放松

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

提前致谢.

解决方法

我同意将聚簇索引放在时间戳列上.我的查询将在fillfactor上 – 100％以牺牲写入性能为代价给出最佳的读取性能.你可能会受到分页的伤害.选择较低的填充因子将延迟页面分割,牺牲读取性能,因此它可以很好地平衡您的情况.

批量删除后,重新建立索引并更新统计信息.这不仅使性能保持不变,而且将索引重置为指定的fillfactor.

最后,是将非聚集索引放在其他适当的列上,但只有非常选择的列,例如不是位字段.但是请记住索引越多,影响写入性能的影响越大