带全文索引的计算列使用CONTAINS查询长数字时异常

嘿，这个问题我碰到过好几次——明明字段里确实有这个数字串，CONTAINS查其他内容都正常，唯独查它没结果，但通配符又能生效，咱们一步步拆解可能的原因：

1. 全文索引的最小词长限制 #

绝大多数数据库的全文索引都有「最小词长」的配置：只有长度超过设定值的词才会被纳入索引。虽然1215041803是10位数字，但有些引擎对纯数字串的处理逻辑不一样，比如单独设置了纯数字的最小索引长度，或者你的数据库默认最小词长刚好卡了某个点？

• 排查步骤：
  比如在SQL Server里，你可以查这个表的全文索引配置：

  SELECT * FROM sys.fulltext_index_columns WHERE object_id = OBJECT_ID('你的表名')
  

  要是用MySQL，就查ft_min_word_len和ft_min_numword_len这两个参数。
• 解决办法：如果确实是词长限制，调整参数后重新生成全文索引就行。

2. 分词器把数字串当成了非索引项 #

很多全文分词器对纯数字串有特殊规则：要么把过长的数字串跳过不索引，要么错误地把它拆成了无法匹配的片段，甚至可能把它误判成了停用词（虽然默认停用词表里很少有纯数字，但不排除自定义停用词表加了类似规则）。

• 排查步骤：
  先试试用CONTAINS查这个数字串的一部分，比如'1215'，看能不能命中——如果能，说明分词器把长数字串拆成了短片段；再去检查数据库的停用词表，比如SQL Server的sys.fulltext_stopwords，看看有没有和这个数字串匹配的条目。
• 解决办法：如果是停用词问题，把这个数字串从停用词表移除；如果是分词规则的问题，要么换个对数字友好的分词器，要么自定义分词规则来保留长数字串。

3. 全文索引没同步或者有碎片 #

虽然通配符能查到，但少数几条记录的索引可能没同步，或者索引有碎片导致匹配失效——这个概率相对低，但也值得排查。

• 排查步骤：
  手动触发一次全文索引的完全重建，比如SQL Server里执行：

  ALTER FULLTEXT INDEX ON 你的表名 START FULL POPULATION
  

  重建完再查一次试试。
• 解决办法：如果是同步或碎片问题，重建索引后应该就能正常匹配了。

4. 字段里藏了看不见的特殊字符 #

有时候字段里的数字串看起来是1215041803，但实际上夹杂了空格、零宽空格这类看不见的字符，导致全文索引无法识别，但通配符因为是模糊匹配，所以能命中。

• 排查步骤：
  你可以查这个字段的长度，或者逐字符检查ASCII码，比如：

  SELECT ASCII(SUBSTRING(searchname, 你找到数字串的起始位置, 1)) 
  FROM 你的表名 
  WHERE 你的主键字段 = '这条记录的ID'
  

  看看每个字符的ASCII码是不是都是数字对应的（48-57）。
• 解决办法：如果确实有特殊字符，清洗字段内容后重新生成索引就行。

总的来说，通配符能查到就说明数字串肯定在字段里，问题出在全文索引没有把它当成可匹配的词来处理，重点排查词长限制、分词规则、停用词这几个方向，应该很快就能找到原因。

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