相关疑难解决方法(0)

索引重建所需的时间是否取决于碎片级别？

如果重建一个 40% 碎片的索引需要 1 分钟，那么重建一个 80% 碎片的索引大约需要 2 分钟吗？

我要求执行所需操作可能需要的 RUNTIME（例如以秒为单位），而不是在什么特定情况下需要哪个操作。我知道应该完成索引重组或重建/统计更新时的基本最佳实践。

这个问题不询问 REORG 以及 REORG 和 REBUILD 之间的区别。

背景：由于设置了不同的索引维护工作（每天晚上，周末的工作更重......）我想知道是否应该在中低碎片索引上更好地执行每日“轻强度”离线索引维护工作以保持关闭时间很小 - 或者甚至无关紧要，并且在 80% 碎片化索引上的重建可能与对同一索引 40% 碎片上的相同操作花费相同的关闭时间。

我遵循了这些建议，并试图找出自己发生了什么。我的实验设置：在测试服务器上不做任何其他事情并且没有被任何人或其他任何人使用，我在唯一标识符主键列上创建了一个带有聚集索引的表，其中包含一些附加列和不同的数据类型 [2 个数字、9 个日期时间和2 varchar(1000)] 并简单地添加行。对于呈现的测试，我添加了大约 305,000 行。

然后我使用了一个更新命令并随机更新了一系列过滤整数值的行，并使用不断变化的字符串值更改了其中一个 VarChar 列以创建碎片。在此之后我检查当前avg_fragmentation_in_percent的水平sys.dm_db_index_physical_stats。每当我为基准创建“新”碎片时，我都会将此值添加physical_page_count到我的记录中，如下图所示。

然后我跑了：Alter index ... Rebuild with (online=on); 并CPU time通过使用STATISTICS TIME ON到我的录音中。

我的期望：我期望至少看到一种线性曲线的指示，显示碎片级别和 CPU 时间之间的依赖性。

不是这种情况。我不确定这个程序是否真的适合一个好的结果。也许行数/页数太少？

然而，结果表明我原来的问题的答案肯定是NO。看起来 SQL Server 重建索引所需的 CPU 时间既不取决于碎片级别，也不取决于基础索引的页数。

第一个图表显示了与之前的碎片级别相比，重建索引所需的 CPU 时间。正如您所看到的，平均线是相对恒定的，碎片化与可观察到的所需 CPU 时间之间根本没有关系。

为了考虑更新后索引中页数变化可能需要或多或少的重建时间的可能影响，我计算了 FRAGMENTATION LEVEL * PAGES …