小编bn2*_*n25的帖子

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

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

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

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

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