含特殊字符时MySQL自然语言全文检索匹配异常问题咨询

你观察到的匹配效果波动、结果不符合预期的问题，全部来自MySQL全文检索在NATURAL LANGUAGE MODE（即当前使用的Natural Language Matches Predicate）下的内置分词、索引、匹配规则，上层查询串的转义、包裹、拆分处理无法绕过这些底层逻辑。

两个异常案例的直接原因 #

• 完整标题搜索返回大量无关结果：自然语言模式默认采用OR匹配逻辑，只要文档包含查询串拆分后的任意一个有效索引词，就会被纳入结果集，仅按相关性权重排序。输入的Guess who's back - tl;dr: Emot在分词阶段会把撇号、短横线、分号、冒号全部识别为分词分隔符，拆成guess、who、s、back、tl、dr、emot等独立token。完全匹配的标题因为命中的有效token最多、词频权重最高排在首位，但其他文章只要命中任意一个拆分后的token（哪怕是s、tl、dr这类极短词）都会被返回，就形成了看到的大量无关结果。
• 搜索tl;dr:无结果：分词阶段冒号、分号被剥离后，tl;dr:会被拆成tl、dr两个长度为2的token。InnoDB引擎默认的最小索引词长innodb_ft_min_token_size为3，MyISAM默认ft_min_word_len为4，长度小于阈值的token在建立全文索引时就会被直接丢弃，根本不会进入索引库，自然检索不到任何结果。

MySQL全文检索的内置固定处理规则 #

之前尝试的双引号包裹、特殊字符替换、按符号拆分查询词等方案无效，核心是没有对齐引擎的底层运行逻辑，其固定规则包括：

• 分词阶段默认将所有非字母、非数字字符判定为分隔符，特殊字符会被直接剥离，不会作为词汇的一部分参与索引。因此tl;dr、IP地址、URL这类带大量特殊符号的内容，建索引时会被拆成零散的短片段，永远不会以完整形式被检索。
• 双引号包裹的短语精确匹配语法仅在IN BOOLEAN MODE下生效，在自然语言模式下，双引号会被当成分隔符直接忽略，不会触发精确匹配逻辑。
• 长度小于服务端配置的最小词长的token，建索引阶段就会被丢弃，该参数为服务端启动级配置，修改后必须重建全文索引才能生效，无库表配置权限时无法调整。
• 命中内置/自定义停用词表的token，会在索引和检索阶段被直接过滤，不参与匹配。
• 自然语言模式下，一个token如果出现在超过50%的被检索文档中，会被判定为无区分度的通用词自动过滤，不参与相关性计算。

可落地的预期边界说明 #

无数据库和全文索引配置权限的前提下，可以明确同步相关方：

• 可稳定支持的能力：长度大于最小词长阈值、不含特殊字符的常规词汇的模糊检索，结果按匹配相关度排序。
• 受底层机制限制无法稳定达成的预期：
  • 带特殊字符的内容（如tl;dr、IP地址、URL、带连字符/撇号的专有名词）的精确匹配
  • 长度小于最小词长阈值的短词检索
  • 强制要求结果仅命中全部查询词、不返回零散匹配单个词汇的无关内容
  • 输入完整短语时的100%精确短语匹配

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