索引重建时间是否取决于碎片级别？
Mag*_*ier 8 sql-server sql-server-2008-r2 fragmentation index-maintenance
索引重建所需的时间是否取决于碎片级别？
如果重建一个 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 COUNT 并在显示所需 CPU 时间关系的第二个图表中使用了该值与碎片和页数。
如您所见，这也并不表示重建所需的时间受碎片影响，即使页数不同。
在做出这些陈述后，我想我的程序一定是错误的，因为重建一个巨大且高度碎片化的索引所需的 CPU 时间可能只受行数的影响 - 我并不真正相信这个理论。
所以，因为我现在真的很想弄清楚这一点，所以非常欢迎任何进一步的评论和建议。
对于感兴趣的每个人，我创建了一个图表，显示了几周内大约 2500 次索引重建的索引 REBUILD 持续时间与索引碎片及其页面大小有关。
此数据基于 10 个 SQL Server、数百个表和Ola Hallengren 的优化程序。重建的一般阈值设置为 5% 碎片。
我删掉了这个统计数据中一些最大的表格（10 Mi + Pages），以使其更具可读性。
该图表将所需的时间（持续时间）显示为气泡的大小。最大气泡的值约为 220 秒。这表明重建索引所需的时间与碎片并没有真正的关系。相反，它似乎更多地取决于索引的页数。这也表明低级碎片比高碎片更耗时。
第二个图表只是放大到 <= 200 K 页的区域。它显示相同，更大的索引需要更长的时间，而不是更多的碎片。
我知道这是旧线程，但我认为在这里分享 Paul Randal 的帖子将会有所帮助。
\n\n\n\n\n\n\n\n算法速度
\n索引重建将始终构建新索引，即使没有碎片。重建所需的时间长度与索引的大小有关，而不是与索引中的碎片量有关。
\n
https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/
\n| 归档时间： |
|
| 查看次数： |
9578 次 |
| 最近记录： |