Sql Server维护计划中的重组索引与重建索引

Question

在“改善SQL Server数据库的SSW规则”中，有一个完整的数据库维护计划示例：SSW。在该示例中，它们先运行重组索引，然后运行重建索引，然后运行更新统计信息。这有什么意义吗？我认为重组索引是重建索引的一个快速但效率较低的版本？并且索引重建也将自动更新统计信息(至少在聚集索引上)。

Answer 1

先对相同的索引执行REORGANIZE，然后再执行REBUILD是没有意义的，因为REORGANIZE所做的任何更改都会因为执行REBUILD而丢失。

更糟糕的是，在来自SSW的维护计划图中，它首先执行SHRINK，这是释放空间方式的一个副作用，它将索引分成碎片。然后，在REBUILD操作期间，REBUILD再次将更多空间作为工作空间分配给数据库文件。

• REORGANIZE是一个联机操作，它使用少量额外的工作space.
• REBUILD逐页整理聚集或非聚集索引中的叶页碎片。在企业版中是一个联机操作，在其他版本中是脱机操作，它使用的额外工作空间与索引大小一样多。它会创建索引的新副本，然后删除旧副本，从而消除碎片。默认情况下，会在此操作过程中重新计算统计数据，但可以禁用该操作。

有关详细信息，请参阅Reorganizing and Rebuilding Indexes。

除非使用TRUNCATEONLY选项，否则不要使用SHRINK，即使这样，如果文件会再次增长，您也应该认真考虑是否有必要：

sqlservercentral_SHRINKFILE

Answer 2

重组和重建是不同的事情。

重组:这是索引的碎片整理。获取现有索引并对现有页面进行碎片整理。但是，如果页面不是连续的，它们会像以前一样。只有页面的内容在改变。

Rebuild:实际上它会删除索引并从头开始重建。这意味着您将获得一个全新的索引，其中包含经过碎片整理的连续页面。

此外，使用rebuild可以更改分区或文件组，但是使用reorganize不仅可以对整个索引进行碎片整理，还可以只对索引的一个分区进行碎片整理。

update statistics在聚集索引上是自动的，但在非聚集索引上不是。

Answer 3

在考虑维护索引之前，回答两个主要问题很重要：

fragmentation?

• What是什么程度的

1. 才是合适的行动？重组还是重建？

如本文http://solutioncenter.apexsql.com/why-when-and-how-to-rebuild-and-reorganize-sql-server-indexes/所述，为了帮助您确定是否应该执行索引重建或索引重组，请了解以下内容：

• 索引重组是SQL Server遍历现有索引并将其清除的过程。索引重建是一个繁重的过程，在该过程中，索引被删除，然后以全新的结构从头开始重新创建，没有所有堆积的碎片和空白页。
• 虽然索引重组是一个纯粹的清理操作，它保持系统状态不变，但没有锁定受影响的表和视图，但重建过程会在整个重建期间锁定受影响的表，这可能会导致长时间的停机，这在某些环境中是不可接受的。考虑到这一点，很明显，索引重建是一个具有“更强”解决方案的过程，但它会带来代价-可能会在受影响的索引表上产生长锁。

另一方面，索引重组是一个“轻量级”的过程，它将以一种效率较低的方式解决碎片问题--因为清理后的索引将始终排在完全从头创建的新索引之后。但从效率的角度来看，重新组织索引要好得多，因为它在操作过程中不会锁定受影响的索引表。

上面提到的文章还解释了如何使用SSMS、T-SQL (在表中重组/重建索引)和名为ApexSQL Backup的第三方工具来重组和重建索引。