为什么Microsoft SQL Server 2016 full-text index未定期爬取更新？

全文索引未自动更新的核心原因 #

1. 变更未同步到全文索引存储 #

SQL Server的全文索引和表的聚集/堆索引是分开存储的，你直接SELECT查询读到的是表的存储引擎数据，而CONTAINS查询走的是独立的全文索引存储。你已经确认了表数据修改成功，说明变更没有同步到全文索引。
你提到同一实例下其他数据库的全文目录也有相同的更新规律，进一步说明是实例级的全文服务异常或者资源不足导致的，和单表配置无关。

2. 自动变更跟踪队列积压 #

全文索引开启automatic变更跟踪后，所有对索引字段的写入会先进入变更队列，由后台fdhost.exe（全文筛选器后台程序宿主）进程异步拉取变更、分词后合并到全文索引中。这个进程的运行优先级远低于SQL Server核心引擎进程，一旦实例CPU、内存、IO资源长期被占满，fdhost.exe会被主动暂停，直到资源空闲才会继续工作，自然就不会处理队列里的变更。
你修改Surname的操作已经进入了变更队列，但后台进程一直没拿到资源处理，所以全文索引里还是旧的分词结果，就会出现只能匹配到旧值的问题。

3. 7月17日之后索引更新零散的根因 #

7月17日大概率发生了以下变化之一：

• 实例侧上线了新的高负载业务，系统资源长期处于高水位，fdhost.exe只有在极少数业务低峰期才能拿到资源运行，所以只会零散出现更新记录
• 全文服务的运行账号权限被调整，导致fdhost.exe无法正常读取数据库的变更日志，只能偶尔在权限校验通过时完成部分爬取
• 实例上其他数据库新增了大量全文索引的写入任务，所有变更队列的处理总资源被占满，只有少部分变更能被处理

无需重建全文目录的修复方案 #

1. 先确认当前全文索引的运行状态，执行以下SQL：

-- 查看customers表全文索引的爬取状态
SELECT 
    crawl_start_date,
    crawl_end_date,
    status_description,
    pending_changes -- 积压的待处理变更数
FROM sys.dm_fts_index_population
WHERE table_id = OBJECT_ID('customers')

如果pending_changes大于0，就说明你的修改确实在积压队列中。
2. 仅针对customers表触发增量爬取即可，不需要重建整个全文目录，性能损耗极低，只会处理未同步的变更：

ALTER FULLTEXT INDEX ON customers START INCREMENTAL POPULATION

3. 如果执行后依然没有更新，去服务器的服务列表中重启「SQL Server 全文筛选器后台程序宿主」服务，这个操作不会影响正常的数据库查询业务，重启后后台进程会重新拉取变更队列处理。
4. 如果要彻底解决更新零散的问题，需要监控7月17日之后实例的资源使用率，若确实是资源不足导致的，可在业务低峰期定时触发所有全文索引的增量爬取，避免变更长期积压。

内容的提问来源于stack exchange，提问作者cartagodre