AG DB 的索引维护

Question

我想就我们目前在我工作的公司进行的索引维护获得一些意见。我们的生产 SQL 2012 集群之一由 4 个节点组成，每个节点上有两个实例，有多个 AG，为一些非常繁重的工作负载提供服务。这些 AG 中的一些数据库是 2TB+。

我们有一个标准的日常索引维护例程，它根据碎片级别进行通常的重建与重组，但我们也只对超过特定大小的索引进行重组，因为如果这些较大的索引要被删除，我们已经看到 SYNC 延迟问题重建。一旦执行了索引维护，我们就会更新统计信息等。

这项工作有时会运行长达 12 小时以上，因此它会影响我们看到流量高峰的关键工作时间，因此我们确实需要采取一些措施来缓解这种情况。

我最近看到了很多评论，有人建议根本不需要维护索引，我怀疑这可能是我们正在对只有 5% 的大型索引进行重组的情况支离破碎。

我想我想要一些关于如何识别索引的想法，这些索引不一定需要我们每天进行的维护级别，除了禁用它并观察影响（如果有的话）。

Answer 1

在进行索引重建时，您并不是唯一看到 AG 同步延迟的人。来自 Sean Gallardy 的博客文章SQL Server Index Maintenance – You're Doing It Wrong（强调我的）：

在最坏的情况下，这似乎确实经常发生，它可以使整个服务器瘫痪，导致长时间阻塞等待，填满日志，导致远程 AG 副本落后，以及大量其他项目. 这确实会产生真实而痛苦的后果。

请注意，该帖子的评论中提到的一个重要警告是碎片会影响 SQL Server 的预读机制的性能，该机制在大型表扫描（ETL 加载、大型报告查询）期间大量使用。

老实说，我喜欢您关于禁用维护并查看会发生什么的建议。您可以仅在非常大的表上禁用它，并查看是否有任何负面影响与您在更短的维护窗口方面获得的收益。

要在您的问题中评论此特定声明：

一旦执行了索引维护，我们就会更新统计信息等。

仅供参考，重建索引将导致该索引的统计信息更新为FULLSCAN. 因此，请确保您不会在这些正在重建的表上两次更新统计信息。

您还应该查看 Erik Darling 的博客文章因为您的索引维护脚本正在测量错误的事情。您可以检查avg_page_space_used_in_percent以确定是否存在可以通过重建来回收大量空间（在磁盘和内存中）的索引。这可能是重建的最大“胜利”。

在相关说明中，Erik 的另一篇文章（重建索引改进了哪些指标？）指出了一些可能需要临时重建的特定情况：

这是我的意见，你可以接受也可以放弃，索引重建应该保留用于特殊情况。

• 你删除了很多数据
• 您需要更改有关索引的某些内容
• 你有一个堆有很多转发的提取

不幸的是，这里没有一个简单的按钮。希望这些链接有助于告知您的决策过程。