相关疑难解决方法(0)

维护全文索引应考虑哪些准则？

我应该重建还是重组全文目录（请参阅BOL）？什么是合理的维护节奏？可以使用哪些启发式方法（类似于 10% 和 30% 碎片阈值）来确定何时需要维护？

（下面的所有内容只是详细说明该问题并显示我到目前为止所想的内容的额外信息。）

额外信息：我的初步研究

有很多关于 b 树索引维护的资源（例如，这个问题、Ola Hallengren 的脚本以及来自其他站点的大量关于该主题的博客文章）。但是，我发现这些资源都没有提供用于维护全文索引的建议或脚本。

有Microsoft 文档提到对基表的 b 树索引进行碎片整理然后在全文目录上执行重组可能会提高性能，但它没有涉及任何更具体的建议。

我也发现了这个问题，但它主要关注更改跟踪（如何将底层表的数据更新传播到全文索引中），而不是可以最大化索引效率的定期维护的类型。

额外信息：基本性能测试

此SQL Fiddle包含的代码可用于创建带有AUTO更改跟踪的全文索引，并在修改表中的数据时检查索引的大小和查询性能。当我在生产数据的副本上运行脚本的逻辑（而不是小提琴中的人工制造数据）时，以下是我在每个数据修改步骤后看到的结果的摘要：

尽管此脚本中的更新语句相当人为，但这些数据似乎表明定期维护可以获得很多好处。

额外信息：初步想法

我正在考虑创建一个每晚或每周的任务。似乎此任务可以执行 REBUILD 或 REORGANIZE。

因为全文索引可能非常大（数千万或数亿行），所以我希望能够检测目录中的索引何时足够碎片化，从而需要进行 REBUILD/REORGANIZE。我有点不清楚什么启发式可能对此有意义。