振荡的片段数量会降低 FTS 查询性能吗？

Question

我有一个FTS Catalog包含 ~10 ⁶行的表。它曾经像魅力一样工作，但最近，由于未知原因，它开始随机出现非常糟糕的（查询> 30 秒）性能。

全文索引维护的阅读指南我仔细研究sys.fulltext_index_fragments并注意到以下几点：

1. 片段数量在2到20之间高频振荡（每分钟多次）；
2. 最大的片段包含约 10 ⁵行，大小为 11Mb；
3. 其他包含 1 到 40 行。

这个波动的片段数量会干扰 SQL Server 的执行计划选择吗？

我能做些什么来清理这个？

Answer 1

如果碎片数量较多，则可能会导致查询性能问题。我通常看到特定全文索引的片段计数大于 50 到 100 个片段。正如您所描述的，20 或更少时通常不明显。如果您看到片段数量从 2 变为 20，然后再次下降，那么听起来主合并正在完成其工作。这表明随着总体运行和碎片的增加，主合并过程正在减少碎片的数量。

执行计划不会因碎片而改变，因为全文是通过 TVF 实现的。因此，无论有多少片段，您在执行计划中看到的只是一个 TVF。如果您看到执行计划发生变化，则可能是由于碎片以外的其他原因造成的。遗憾的是，目前无法查看 TVF 中实际存在哪些查询来解决您的全文搜索请求。您的搜索请求越复杂，全文可能需要做的工作就越多。

如果您遇到计划更改并认为全文是计划更改的原因，则更有可能是由于 TVF 预计返回的估计/实际行数。另一件可能影响性能的事情是 TVF 连接到表的点以及计划是先处理 TVF 还是先处理表。全文搜索条件显然会影响返回的行数，因此我要问的一个问题是，对于相同的确切搜索词，您是否会重复获得相同的性能？性能会随着搜索词的变化而变化吗？查询是否有任何等待统计信息或者查询是否被阻止？所有这些都可能有助于进一步理解事物。

需要做更多的工作才能充分理解为什么全文性能会出现变化。

更多信息 碎片是在填充过程中创建的。这有助于加快人口进程。在内部，每个片段都是一个单独的表，因此可以将查询大量片段视为所有片段表的 UNION。正如您可以想象的那样，它们越少，性能就越好。

很多全文用户对重建常规索引感到困惑，认为也需要“重建”全文索引，但实际上恰恰相反。

全文目录的重建会导致索引碎片，因为重建正在执行完整填充，并且填充会创建碎片以加速填充。仅当全文索引损坏或更改分词器、ifilter、停止列表 - 基本上任何会更改索引中存储内容的内容时，才应重建全文索引。

在完全填充或增量填充结束时，主合并过程（减少碎片）会自动运行。但是，可以同时运行的并发合并进程的数量是有限的。理解这一点尤其重要，因为如果您在 SQL 实例上有很多全文索引，或者您将多个全文索引放入同一个全文目录中，并且您要么重建或重新组织，并且多个索引的填充接近完成或者同时它可以超过阈值。这可能会导致那些超过阈值的合并进程的碎片进入等待状态，最终结果是受影响的全文索引的碎片不会减少。查看全文人口缓慢

希望这可以帮助。