SQL Server全文搜索故障排查：相同值查询结果不一致问题

先拆解你遇到的现象可能的原因，再给你几个分析全文索引内容的实用方法：

可能的原因拆解 #

1. nchar(32)的固定长度空格陷阱
   nchar是固定长度类型，字符串长度不足32位时会自动在末尾填充空格。而SQL Server的全文检索默认会忽略字符串末尾的空格进行索引。假设你的3行数据实际存储的是带末尾空格的相同前缀值（比如'ABC' + 29个空格），普通的精确查询（比如WHERE col = 'ABC'）会自动把查询值补全为nchar(32)带空格，所以能匹配到3行；但全文索引在处理时会去掉末尾空格，将这3行的索引词统一为'ABC'——但为什么CONTAINS只返回1行？大概率是其中两行的全文索引条目没有被正确更新，或者自动变更跟踪没有同步这些行的变更。

2. 全文索引的自动变更跟踪延迟或异常
   虽然你启用了自动变更跟踪，但有时候会因为事务锁、服务暂停等原因导致变更没有及时同步到全文索引。需要注意的是，你更新的普通统计信息和全文索引的统计是分开的——普通统计针对关系型索引，全文索引有自己的爬网和索引维护机制。

3. CONTAINS查询的语法与词解析问题
   你提到去掉CONTAINS的引号会报错，这是因为不带引号时，全文检索会把查询内容拆分成多个词（由当前使用的断词器决定）。如果你的nchar(32)列存储的是类似连续无分隔的字符串（比如GUID的32位十六进制值），断词器可能无法识别为单个词，从而触发语法错误或无匹配结果。而带引号的短语查询会强制全文检索匹配完整的连续字符串，但如果索引时的词和查询词存在空格差异，就可能出现匹配不全的情况。

如何分析全文索引的实际内容 #

要定位问题，直接查看全文索引里的内容是最有效的，给你几个实用的SQL查询：

1. 查看每一行的索引关键词 #

这个查询可以帮你确认目标列的每一行（document_id对应表的主键）被全文索引成了什么词：

SELECT 
    document_id, -- 对应表的主键值
    display_term, -- 可读的索引词
    keyword, -- 哈希后的索引词
    column_id
FROM 
    sys.dm_fts_index_keywords_by_document(DB_ID('你的数据库名'), OBJECT_ID('你的表名'))
WHERE 
    column_id = (SELECT column_id FROM sys.columns WHERE name = '你的nchar列名' AND object_id = OBJECT_ID('你的表名'))
ORDER BY 
    document_id;

对比这3行的display_term，看看是不是一致，有没有哪行没有被索引到，或者索引词和你预期的不同（比如少了空格）。

2. 测试查询词的解析结果 #

用sys.dm_fts_parser模拟全文检索对查询词的解析过程，看看你的查询字符串会被转换成什么索引词：

SELECT 
    display_term,
    occurrence,
    keyword
FROM 
    sys.dm_fts_parser('"你的列的实际值"', 1033, 0, 0); -- 1033是英文LCID，换成你数据库对应的LCID

如果解析后的display_term和你在第一步查到的索引词不一致，那就是解析规则导致的匹配问题。

3. 检查全文索引的状态 #

确认全文索引是否正常启用、变更跟踪是否在运行、爬网是否完成：

SELECT 
    name AS 全文索引名,
    is_enabled AS 是否已启用,
    change_tracking_state_desc AS 变更跟踪状态,
    has_crawl_completed AS 是否已完成爬网
FROM 
    sys.fulltext_indexes
WHERE 
    object_id = OBJECT_ID('你的表名');

如果变更跟踪状态不是AUTO，或者爬网未完成，那就是索引维护的问题，需要手动触发一次完整爬网：

ALTER FULLTEXT INDEX ON 你的表名 START FULL POPULATION;

快速验证方案 #

你可以先手动触发一次全文索引的完整爬网，然后重新执行CONTAINS查询。如果结果还是不对，用上面的查询查看索引内容，确认那3行的索引词是否一致。如果索引词一致但查询只返回1行，那可能是表的主键或全文索引的关联出现了异常，需要重新创建全文索引。

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