我认为您的问题是由分词器与数据中的标点符号交互的不可预测性引起的。全文搜索基于字符串的概念,不包括空格和标点符号。当引擎构建索引时,它会看到句点并以奇怪的方式中断单词。
例如,我用您提供的三个值制作了一个小表格......
VALUES (1,'3.7.21.1'),(2,'3.7.21'),(3,'3.72.21')
现在,当我做你的选择时,我得到了所有四个的结果……但不是我期望的结果。
对我来说,这将返回所有三个值
SELECT * FROM containstext WHERE CONTAINS(secondid, '"3.7.2*"')
这只返回3.7.21
SELECT * FROM containstext WHERE CONTAINS(secondid, '"3.7*"')
所以让我们运行一下,看看全文索引的内容
SELECT * FROM sys.dm_fts_index_keywords(db_id('{databasename}'), object_id('{tablename}'))
对于我的结果(您的结果可能完全不同),我有以下 display_term 值
display_term document_count
21 3
3 3
3.7.21 1
7 2
72 1
所以让我们看看第一个搜索条件'"3.7.2*"'
如果我把它推到sys.dm_fts_parser......
select * from sys.dm_fts_parser('"3.7.2*"', 1033, NULL, 0)
...它向我展示了它正在与比赛中断
3
7
2
但如果我这样做...
select * from sys.dm_fts_parser('"3.7*"', 1033, NULL, 0)
我得到了一个完全匹配的术语3.7,并且sys.dm_fts_index_keywords早些时候告诉我,我只有一个文档/行包含3.7
您可能还会遇到额外的怪异,因为数字 0-9 通常在系统停用词中,并且可以被排除在索引之外,因为它们被认为是无用的。这可能就是当您更改为字母时它起作用的原因。
另外,我知道您已决定替换 LIKE,但 Microsoft建议您在全文索引中仅使用字母数字字符,如果您需要在搜索条件中使用非字母数字字符,则应使用 LIKE。也许将句点更改为一些不会在正常值中使用的字母数字替换?