为什么全文索引落后了？

Question

我在表上设置了全文索引；该表处于相当恒定的负载下，每天接收约 50k 插入和约 35k 删除，插入之间的间隔相当短（最多 5 分钟）。
该索引配置为自动更改跟踪，通常能够在插入后几秒钟内处理所有文档。但昨天监测提示，该指数已超过4小时未更新。
收到该警报后，我检查了以下内容：

• 全文日志中没有出现新条目。最后一个条目是信息性的 - 全文自动填充已完成。
• 索引填充状态（由 sys.dm_fts_index_population 报告）停留在“已停止处理”状态。
• 运行命令“FT BATCH CMPLETE”的单个会话耗尽了整个 CPU 核心。该会话的last_request_start_time 距全文日志中最后一个条目的秒数以内。除此之外，CPU 处于空闲状态。
• 两个（共 30 个）片段的状态为 6 / 正在用于合并输入并准备好查询（如 sys.fulltext_index_fragments 所报告）；这些碎片的大小每个接近 60GB。

大约 10 小时后，索引编制又神秘地恢复了，就像它停止了一样。

我认为索引因合并而暂停的想法正确吗？如果不是，我还可以检查什么以获得更好的诊断？

该问题大约每月在不同服务器上发生两次。据我所知，该索引没有按计划重组或重建。我正在寻找一种解决方案，可以让我完全避免索引暂停，或者在维护停机期间安排索引暂停。服务器是 SQL Server 2012 Enterprise。

Answer 1

显然 MS SQL Server 2012 无法并行运行多个索引线程。由于索引线程可能会在完成对当前批次文档的索引后运行合并，因此索引暂停是不可避免的。

手动更改跟踪没有帮助。当合并运行时，在单独会话上运行的多个 UPDATE POPULATION 命令也会相互阻止。

可以控制正在合并的片段的大小，例如通过重新组织索引。重组操作将所有索引碎片合并为一个。reorganize 创建的片段太大，无法合并，而新片段相当小，因此合并速度很快。

在我们的例子中，新的索引碎片需要几周的时间才能达到数千兆字节，并且每周重组是一种选择。