索引重组/重建时间

Question

我在SQLServer2012EnterpriseEdition上有维护工作，它每天运行以检查索引碎片，并根据碎片百分比重新组织或重建索引。我使用这种方法来提高性能，而且它很长一段时间工作得很完美。然而，最近这种方法开始花费太多的时间。

因此，我不使用上面的内容，而是执行索引重建。它以第一种方法所需时间的一-六时间完成。

为什么第一种方法会随着时间的推移变得缓慢，以及为什么完整的指数重建会变得更好？

EXECUTE dbo.IndexOptimize @Databases = 'MyDBname'
    , @FragmentationLow = NULL
    , @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE'
    , @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE'
    , @FragmentationLevel1 = 5
    , @FragmentationLevel2 = 30
    , @UpdateStatistics = 'ALL'
    , @OnlyModifiedStatistics = 'Y'

Answer 1

您没有说明在每一种情况下所采取的步骤，因此很难给出具体的分析，而是对其中一些差异进行三种一般性解释：

• 除非您正在使用Enterprise，否则重构是一种脱机操作，因此它需要一个表锁，并在允许任何其他进程接触它之前完成所有工作。这意味着流程可以为自身优化，而不关心并发性，或者不关心在process.重组期间发生的更改是一种在线操作，因此它需要关注可能的并发操作:对并发性的优化通常意味着要做比其他事情更多的工作，如果存在任何并发活动，则需要处理IO带宽和吞吐量的过程。
• 重建只是丢弃现有索引并从表数据中重新构建，重组更“聪明”，并且移动和压缩现有页面，这取决于页面分布的状态、I/O子系统、索引的页面现在在RAM中的多少、集群/堆在RAM中的多少、集群/堆在磁盘上的碎片化程度，如果可以使用另一个索引来帮助重建，以及许多其他因素，可能会使重组更慢。
• 如果您没有首先检查(并且只是重建)，那么您将跳过第一个任务所做的工作的一部分:您只需重新构建而不是扫描，然后重建或重组。

https://www.brentozar.com/archive/2013/09/index-maintenance-sql-server-rebuild-reorganize/还有一些其他的注意事项，您可能会发现它们在更多地理解差异方面很有用。

要想得到更具体的答案，您需要更新您的问题，并提供您正在比较的维护计划的更多细节。