重建超大主键索引

Question

我有一个托管在 Azure 上的 SQL 数据库。问题是大小越来越失控，我可以在主键聚集索引中看到高达 99% 的碎片。

我可以使用online=on选项重建所有其他索引，并且不会影响性能。PK Clustered 索引之一的大小大于 200GB，因此 aREBUILD...WITH (ONLINE=ON)会导致锁定。

我们确实有来自所有时区的用户访问该站点，所以真的，我无法找到可以离线重建索引的时间。

在站点不停机的情况下重建大型索引的最佳策略是什么？

我相信重组无济于事，因为碎片化是 99%。问题是即使在线，表也会被锁定。主要问题是索引大于200GB。主键是一个整数。

Answer 1

即使有点晚了，我还是会做出回应，希望它有所帮助，或者至少摒弃关于这个问题的一些其他想法/评论，因为我认为这是一个很好的问题。

首先，我不知道您是否正在这样做，但请不要假设索引上的高碎片级别总是会导致性能不佳。与单独的碎片相比，陈旧的统计数据（例如sys.dm_db_stats_properties）和每页大量空白（即sys.dm_db_index_physical_stats dmv 中的 avg_page_space_used_in_percent 列）与性能问题更相关。是的，高度碎片化的索引会产生更多的预读，您通常会看到陈旧的统计数据和每页更高级别的空白空间以及碎片，但碎片与查询计划优化或从磁盘加载索引的内存量没有直接关系实际上会消耗。 查询计划受统计数据的影响，并且您的内存占用会因更多空白而膨胀。例如，一个索引 99% 的碎片化但低于 5% 的平均值。与由于过时的统计数据导致的错误执行计划或因太大而无法完全放入内存的索引的不断分页相比，空白和最新的统计数据可能不会导致严重的性能问题，因为有大量每页存在的空白空间。

如果碎片化确实是一个问题，您可以在线减少它，方法是ALTER INDEX ... REORGANIZE发表 Dan Guzman 在评论中指出的声明。这不会像REBUILD操作那样创建精简的索引，但它会减少您的碎片。这里的关键是识别数据库上使用率较低的窗口，然后运行它。这可能是 15 分钟或多个小时，显然越长越好，但这里的关键是此操作不会回滚并保留任何进展，即使您在执行中杀死它。

如果在消除碎片的完美世界中，在此表上使用分区是否更有意义？ Azure SQL 数据库确实允许表分区，Microsoft 有一篇很棒的文章概述了Azure SQL 数据库的一些分区策略。如果您的数据是非易失性的，对它进行分区可能有助于减少维护需求，如果与表压缩结合使用，您甚至还可以减少整体存储占用空间。Alberto Murillo较早的回答暗示使用水平分区 基于数据区域，这种方法可能有助于为您创建一些维护窗口，因为您的数据将更具区域性而不是全球性。

由于当前没有维护时段，转换到分区表并不容易，但您可以使用Maria Zakourdaev概述的方法，该方法使用当前表顶部的分区视图和新的分区表来开始分区未来数据。随着时间的推移（希望您的旧数据被清除），您最终可以完全过渡到分区表。同样，我不知道您的数据或应用程序，但也许您可以采用这种方法。

Answer 2

尝试使用分片来按地理分布数据库的数据。然后，您将能够为每个地理位置确定不同的维护时段，并且进行维护的时间将会更短。这也将提高性能。您可以通过这篇文章了解更多信息。不要等待数据库变大。

对于大型数据库和用户 24 x 7 连接的情况，您需要使用索引重组并仅更新需要更新的统计信息（sp_updatestats），以最大限度地减少维护所需的时间和对用户的影响。

希望这可以帮助。