SQL Server全文搜索带空格相邻重复词时通配符查询无结果

问题现象 #

使用带通配符的全文搜索谓词检索时，无法命中字段中包含「空格分隔连续重复词」的记录，但可以正常命中无空格连写重复词的记录。
复现场景：

• 检索谓词："other*"
• 可正常命中的字段内容：otherother（两个other无空格拼接）
• 无法命中的字段内容：other other（两个other中间带空格）

使用的查询语句如下：

SELECT p.*, KEY_TBL.RANK  
FROM dbo.Person AS p WITH (NOLOCK)
INNER JOIN CONTAINSTABLE (dbo.Person, PersonFullName, @QueryPredicate, LANGUAGE N'English', @RowCount) AS KEY_TBL ON p.PersonId = KEY_TBL.[KEY]
ORDER BY KEY_TBL.RANK DESC

问题根因 #

这个现象和空格本身无关，是SQL Server全文索引的英文分词规则、前缀匹配边界共同作用的结果，仅会在相邻完全重复词的场景触发：

• 分词处理逻辑差异：查询中指定了LANGUAGE N'English'参数，全文引擎会调用对应LCID为1033的内置英文断字符，分别处理索引构建阶段的字段内容、查询阶段的检索词：
  • 无空格连写的otherother不会被断字符拆分，会作为单个独立分词项存入全文索引，词条本身以other开头，自然能被"other*"的前缀规则命中。
  • 带空格的非重复组合比如other test，会被拆分为other、test两个独立有效分词，搜"other*"时可以正常命中。
  • 带空格的相邻重复组合other other，虽然会被断字符识别出两个other片段，但英文断字符默认会对紧邻、仅用空白字符分隔的完全重复词做索引压缩：第二个重复的other不会被标记为有效可匹配分词，仅作为前一个词的位置冗余信息记录。
• 前缀通配符的匹配限制：CONTAINSTABLE中的"xxx*"前缀匹配规则，仅会对标记为有效独立分词的词条做前缀校验，被标记为重复冗余的分词不会进入候选匹配集，因此存储了other other内容的记录无法被命中。
• 快速验证方法：执行系统函数SELECT * FROM sys.dm_fts_parser('"other other"', 1033, 0, 0)查看英文分词结果，再和SELECT * FROM sys.dm_fts_parser('"other test"', 1033, 0, 0)的结果做对比，就能看到重复词项的特殊标记差异。

解决方案 #

按改动成本从低到高可选：

• 方案1：调整查询谓词，显式覆盖重复词场景
  不需要改动现有索引配置，把传入@QueryPredicate的内容从单一前缀匹配调整为多条件匹配，比如原来传'"other*"'，改成'"other*" OR "other other*"'即可覆盖相邻重复词的匹配场景，适合临时修复、业务逻辑改动成本低的场景。
• 方案2：调整字段的全文索引分词语言
  如果PersonFullName字段不需要英文分词自带的词干提取、变体匹配、重复词压缩能力，可以把全文索引中该字段对应的分词语言修改为「非特定语言」（对应LCID 0）。该断字符只会按空格、标点做机械拆分，不会对相邻重复词做特殊压缩处理，所有拆分出的词都会作为有效分词进入索引，前缀匹配不会漏结果。注意修改后需要重新填充全文索引才能生效。
• 方案3：自定义分词规则
  如果需要保留英文分词的其他能力，可以注册自定义断字符，关闭相邻重复词的压缩逻辑，这个方案改动成本最高，适合对全文检索召回率要求严格的生产场景。

现有查询的额外注意点 #

当前在基表查询时加了WITH (NOLOCK)提示，当全文索引和基表数据存在同步延迟时，可能出现匹配到的全文键在基表读取时缺失、或者基表已更新数据未同步到全文索引的不一致问题，如果业务对数据一致性要求较高，建议移除该提示。

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