在什么情况下每晚重新索引表是个好主意?

在什么情况下每晚重新索引表是个好主意?

我继承了许多 SQL Server 2005 和 2008 系统(全部在简单恢复模式下运行),每个系统目前每晚都从 SQL 代理任务执行以下操作:

  • 备份
  • 收缩
  • 重新索引

我已经阻止了缩减的发生,因为这可能会导致比它解决的问题更多的问题。(服务器的用途是按连续 5 天存储一致数量的信息,因此删除行的空间将再次用于存储新信息,而不会增长太多)。

但是,我不知道是否也应该停止夜间重新索引作业。由于收缩会导致大量索引碎片,因此在收缩处于活动状态时,这是必要的。我在网上找不到太多信息来建议何时进行夜间重新索引可能是合理的。我也应该禁用它吗?

答案1

如果信息滚动,则表明每天插入的数据库总量很大一部分(大约 20%)。这表明您的统计数据和索引有 20% 是错误的。

这听起来正是您应该重新索引的条件。

答案2

基本上,您的收缩和重新索引只是相互撤消(收缩碎片表以恢复空间,然后重新索引使用额外的空间对表进行碎片整理)。

既然你已经移除了心理医生,你大概也可以删除每晚的重新索引。(在大多数情况下,仍然建议每周进行一次完整重新索引。)

但考虑到连续 5 天的数据,你可能实际上会接受无需重新索引在这些滚动表上根本没有任何关系(具体取决于聚集索引的配置方式)。我的意思是:

假设你这样做仅插入(无更新),并且聚集索引要么在日期/时间,要么只是一个不断增加的数值,内部表排列可能看起来像:

[  Day 1  ][  Day 2  ][  Day 3  ][  Day 4  ][  Day 5  ][  Empty  ]

在第 6 天,删除第 1 天的数据,并插入第 6 天的数据:

[  Empty  ][  Day 2  ][  Day 3  ][  Day 4  ][  Day 5  ][  Day 6  ]

并且相同的模式继续,重新使用最近释放的空间:

[  Empty  ][  Day 2  ][  Day 3  ][  Day 4  ][  Day 5  ][  Day 6  ]
[  Day 7  ][  Empty  ][  Day 3  ][  Day 4  ][  Day 5  ][  Day 6  ]
[  Day 7  ][  Day 8  ][  Empty  ][  Day 4  ][  Day 5  ][  Day 6  ]
[  Day 7  ][  Day 8  ][  Day 9  ][  Empty  ][  Day 5  ][  Day 6  ]

要确定是否发生了这种情况,我会在最后一次重新索引后使用 SQL 的表碎片查询 (dm_db_index_physical_stats),然后关闭重新索引几天。如果碎片数非常低,那么很可能就是这种情况。如果碎片数很高,那么这可能不是准确的描述,您可能需要恢复重新索引。

相关内容