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

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

如果重建相同索引的40％碎片索引需要1分钟，重建80％碎片索引大约需要2分钟吗？

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

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

背景：由于设置了不同的索引维护作业（每个晚上，周末工作量较大……），我想知道是否应该对低中级零散的索引更好地执行每日“轻度”离线索引维护作业，以保持关闭时间很小-甚至没有关系，在80％碎片索引上进行重建可能需要与在40％碎片索引上进行相同操作的时间相同。

我遵循了建议，并试图找出自己正在发生的事情。我的实验设置：在没有其他操作且未被任何人或其他任何人使用的测试服务器上，我在uniqueidentifier主键列上创建了带有聚簇索引的表，其中包含一些其他列和不同的数据类型[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时间之间的依赖关系。

不是这种情况。我不确定此程序是否真的适合取得良好效果。也许行数/页面数太少？

但是结果表明，我最初的问题的答案肯定是“ 否”。看起来SQL Server重建索引所需的cpu时间既不依赖于碎片级别，也不依赖于基础索引的页数。

第一张图表显示了与先前的碎片级别相比，重建索引所需的cpu时间。如您所见，平均线是相对恒定的，碎片与所需的cpu时间之间根本没有关系。

为了尊重更新后索引页数变化可能会影响重建的时间的影响，我计算了FRAGMENTATION LEVEL * PAGES COUNT并在第二张图表中使用了该值，该图表显示了所需cpu时间的关系以及碎片和页数。

如您所见，即使页面数有所变化，这也并不表示重建所需的时间受碎片影响。

在做出这些陈述之后，我想我的程序一定是错误的，因为重建一个庞大且高度分散的索引所需的cpu时间可能仅受行数的影响-我并不真正相信这一理论。

因此，因为我确实非常想立即发现这一点，所以欢迎任何进一步的评论和建议。

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

我相信这将不是SQL Server决定的主要参数，并且需要花费一些时间来重建\重新组织索引：

根据“ DATA”还涉及其他各种因素，通过这些因素可以决定需要多少时间：

因素1：表大小

因素2：可用性关注

因素3：分区

因素4：索引列和唯一性

如果您想了解更多有关这些因素的信息，请参见此处。

如果重建相同的碎片索引为40％的索引需要1分钟，那么重建80％的碎片索引大约需要2分钟吗？

同样，答案可能取决于它！对于编号，您将需要测试场景并查看输出如何进行。跟踪诸如FRAG级别80这样的详细信息，重建花费X hrs \ mins \ secs，对于Frag级别40，重建花费Y hrs \ mins \ secs。计算并保留15天内的历史记录（取决于计划的维护活动），您可以得出一个结论，即在比较两者时实际花费了多少时间。

另外：

您可以收集有关索引重建进度的数据\计算：

使用DMV sys.dm_exec_requests或

如果您有Ola的重新索引编制-重新组织维护计划，则可以选择将维护期间执行的操作的历史记录保存在表CommandLog中，如SQL Server索引和统计信息维护中所述。保存数据后，您可以查询命令类型“ ALTER_INDEX--REBUILD”，并在START TIME和END TIME列之间查询相同的差异

对于感兴趣的每个人，我都创建了一个图表，该图表显示了在几周内与索引的碎片及其在页面中的大小有关的大约2500次索引重建的索引重建持续时间。

此数据基于10个SQL Server，表的百分表和Ola Hallengren的优化过程。重建的一般阈值设置为5％的碎片。

我已删除此统计信息中一些最大的表（10 Mi +页），以使其更具可读性。

图表将所需时间（持续时间）显示为气泡大小。最大气泡的值约为220秒。它表明重建索引所需的时间实际上与碎片无关。相反，它似乎更多地取决于索引的页数。这也表明低级别的碎片比高级别的碎片更耗时。

第二张图表只是放大到<= 200 K Pages区域。它显示出相同的结果，较大的索引花费的时间更长，而不需要更多的碎片。

REBUILD索引的大小不取决于碎片。它会完全删除索引并从头开始创建索引。

REORGANZE 索引-用于减少碎片而无需重建索引，因此不会删除和创建。

MS建议使用Reorganize进行30％或更少的碎片处理。对于更高的碎片，首选重建。

这是有关此的MSDN文章：重组和重建索引

更新

就完成操作所花费的时间而言，它显然取决于索引碎片。重建庞大的索引将比重组花费更少的时间。重建稍微零散的索引将花费更长的时间。我建议以MS准则为起点，并在您的表上运行一些测试。就碎片百分比而言，盈亏平衡点将取决于特定的表，索引大小和数据类型。

如果同一索引的40％碎片索引的重建需要1分钟，重建80％的碎片索引大约需要2分钟吗？

REBUILD与REORG的算法不同。REORG不会分配新范围，而不是REBUILD。REORG将与当前分配的页面配合使用（分配一个8Kb随机页面，以便它可以左右移动页面），然后将它们移动，然后根据需要取消分配页面。

从我的SQLSkills内部结构（以前为IE0）注释...。

对于重建：

• 它可以使用多个CPU-可以利用并行性来快速完成工作。
• 对于高度分散的索引（例如，在您的示例中为80％），REBUILD将比REORG快得多。REBUILD只会创建索引的另一个副本，而REORG会陷入删除碎片的困境，因此速度会更慢。这就是Paul Randal提出一般建议的原因因为这样做最好重建索引高度分散的索引。
• 使用REBUILD，您可以通过生成较少的日志记录，将恢复模式更改为BULK_LOGGED，以减少在那里的日志记录。

对于索引REORG：

• 它始终是单线程的。没有并行性。
• 对于高度零散的索引，它的速度较慢；对于轻度零散的索引，速度则较快。创建索引与进行小片段索引的重组相比，创建索引的成本更高，因此对于小片段索引，REORG将更快。
• REORG始终是完全记录的操作。

继续阅读- 注释-SQL Server索引碎片，类型和解决方案

我知道这是旧话题，但是我认为在这里分享Paul Randal的帖子将是有益的。

算法速度

索引重建将始终建立一个新索引，即使没有碎片。重建花费的时间长短与索引的大小有关，而不与其中的碎片数量有关。

https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/

是的，因为通常重建需要按顺序扫描原始索引，同时将行（按顺序）传输到新的物理索引分区中。碎片会伤害未缓存的扫描，因此，重建将花费更长的时间。

更长的时间取决于碎片以及整个过程对CPU的约束。对行进行序列化会占用大量CPU，因此可能根本没有关系。或者，您可能会获得通常为1.5MB /秒的随机IO速率，这比快速重建的速度要慢5-10倍（取决于架构和数据）。根据您做出的假设，您可能可以设想1倍到100倍的减速。

如果同一索引的40％碎片索引的重建需要1分钟，重建80％的碎片索引大约需要2分钟吗？

这不是线性关系。碎片度量标准是扫描分区需要多少时间的非常粗略的代理。