我应该重建还是重新组织全文目录（请参阅BOL）？什么是合理的维护节奏？可以使用什么启发式方法（类似于10％和30％的碎片阈值）来确定何时需要维护？
（下面的所有内容只是关于此问题的详尽信息，并显示了我的想法）
其他信息：我的初步研究
关于b树索引维护的资源很多（例如，该问题，Ola Hallengren的脚本以及其他网站上有关该主题的大量博客文章）。但是，我发现这些资源都没有提供用于维护全文索引的建议或脚本。
有Microsoft文档提到对基础表的b树索引进行碎片整理，然后在以下位置执行REORGANIZE全文目录可能会提高性能，但是并没有涉及任何更具体的建议。
我也发现了这个问题，但它主要侧重于变更跟踪（数据如何更新到基础表将传播到全文索引中），而不是可以使索引效率最大化的定期维护类型。
附加信息：基本性能测试
此SQL Fiddle包含可用于通过
AUTO更改跟踪创建全文索引的代码，并在修改表中的数据时检查索引的大小和查询性能。当我在生产数据的副本（而不是小提琴中的人造数据）上运行脚本的逻辑时，以下是在每个数据修改步骤后看到的结果的摘要：
尽管此脚本中的更新语句相当虚构，但此数据似乎表明定期维护有很多好处。
额外信息：初步构想
我正在考虑创建每晚或每周的任务。看来此任务可以执行REBUILD或REORGANIZE。
由于全文索引可能很大（几千万或几亿行），我希望能够当目录中的索引足够分散时，需要进行REBUILD / REORGANIZE。对于哪种启发式方法可能有意义，我还不清楚。
#1 楼
我无法在网上找到任何好的资源，因此我进行了一些动手研究，并认为发布根据我们的研究结果正在实施的全文维护计划将很有用。我们的启发式方法确定何时需要维护
我们的主要目标是随着基础表中数据的发展而保持一致的全文查询性能。但是，由于种种原因，对于我们来说，每晚都很难对我们的每个数据库发起具有代表性的全文查询套件，并利用这些查询的性能来确定何时需要维护。因此，我们希望创建可以快速计算的经验法则，并将其用作启发式方法，以表明可能需要对全文索引进行维护。
在探索过程中，我们发现系统目录提供了大量有关如何将给定的全文本索引分为多个片段的信息。但是，没有计算官方的“碎片百分比”（就像通过sys.dm_db_index_physical_stats的b树索引一样）。基于全文片段信息，我们决定计算自己的“全文片段％”。然后，我们使用开发服务器反复对100到25,000行之间的任意位置重复进行一次随机更新，以更新到生产数据的1000万行副本，记录全文碎片，并使用
CONTAINSTABLE执行基准全文查询。 br /> 上图和下图所示的结果非常有启发性，表明我们创建的碎片测量与观察到的性能高度相关。由于这也与我们在生产中的定性观察相联系，因此足以让我们满意地使用碎片％作为启发式方法来确定何时需要维护全文索引。
维护计划
我们决定使用以下代码为每个全文本索引计算碎片百分比。任何不重要的，不小于10％的碎片的全文索引都将标记为由我们的通宵维护重新构建。
查询会产生如下结果，在这种情况下，第1、6和9行将被标记为过于分散，无法获得最佳性能，因为全文索引超过1MB，并且至少有10％处于碎片状态。
维护节奏
我们已经有一个夜间维护时段，而碎片计算的计算成本非常低。因此，我们将每天晚上运行此检查，然后仅在需要时才根据10％的碎片阈值执行实际重建全文索引的更昂贵的操作。
REBUILD与REORGANIZE与DROP / CREATE
SQL Server提供了
REBUILD和REORGANIZE选项，但是它们仅可用于全文目录（其中可能包含任意数量的全文索引）。由于遗留原因，我们有一个包含所有全文索引的全文目录。因此，我们选择删除（DROP FULLTEXT INDEX），然后在单个全文索引级别上重新创建（CREATE FULLTEXT INDEX）。将全文索引分为单独的目录可能更理想以合乎逻辑的方式执行
REBUILD，但是拖放/创建解决方案在此期间对我们有用。