重build索引后，为什么索引重组需要3倍？
我不确定是否每次都发生这种情况，所以我在上个月做了一个testing。 我configuration了SSMS，每天（凌晨4点）执行索引重组计划，以及每周（星期日上午5点）在线索引重build，而不pipe碎片级别。 重build被设置为填充85％的页面。
让我困扰的是，重build之后的第一次重组每次都花费更长的时间，而且没有任何意义（至less在我理解每个操作的作用的情况下）是没有意义的。
您可以检查在线重build（重新组织之前）和重build之后首次重新组织之后为索引分配的页数是多less？ 检查total_pages中的sys.allocation_units 。 我怀疑重组是在重build之后压缩索引，从而移动了相当多的数据。