在数据处理过程中，我们经常会遇到这样一种情况：主表里的某一行记录需要通过一段自由文本，去关联另一张表里最相近的若干条记录。传统做法是用LIKE做模糊匹配，但在数据量变大后性能急剧下降，而且无法区分关键词出现一次和出现多次的权重差异。利用数据库自带的全文索引，可以把文本字段预先切词并建立倒排列表，在查询时直接根据关键词命中情况和词频计算相似度，从而实现高效的模糊连接。
全文索引的基本原理与词频统计机制
全文索引（fulltext index）并不是像B树那样逐字符比较，而是先对文本做分词，把每个有意义的关键词抽出来，记录它们在哪些行出现以及出现的频次。以MySQL的InnoDB全文索引为例，它会维护一个倒排索引结构，其中包含关键词、文档标识以及词频信息。当我们执行MATCH col AGAINST('关键词')时，引擎会直接定位到倒排列表，而不需要扫描整张表，因此即便在百万级数据上也能保持毫秒级响应。
关键词频次在相关性计算中扮演核心角色。MySQL的MATCH AGAINST返回的是一个浮点相关性分数，这个分数综合考虑了词频（TF）、逆文档频率（IDF）以及字段长度归一化。也就是说，某个关键词在目标行中出现次数越多，且在整个表里越稀有，得分就越高。理解这一点非常重要，因为我们要做的模糊连接，本质上就是按这个相关性分数把右表记录关联到左表。
需要注意的是，全文索引默认有停用词（stopword）机制和最小词长限制。例如英文默认忽略the、and等高频无意义词，中文在较低版本中甚至不被原生支持，需要借助ngram分词器。如果业务关键词包含被过滤的停用词，频次统计就会失真，因此建索引前要确认分词配置是否符合你的文本特征。
使用MATCH AGAINST实现基于词频的模糊连接
假设我们有两张表，article表存放待关联的长文本，tag表存放关键词及其说明。我们希望把article中命中tag关键词最多、频次最高的记录关联出来。首先为article的content字段和tag的keyword字段分别建立全文索引：
CREATE TABLE article ( id INT PRIMARY KEY, content TEXT, FULLTEXT INDEX ft_content (content) WITH PARSER ngram ); CREATE TABLE tag ( id INT PRIMARY KEY, keyword VARCHAR(50), FULLTEXT INDEX ft_keyword (keyword) WITH PARSER ngram );
接下来，利用MATCH AGAINST把article和tag做交叉关联。由于tag.keyword本身是短文本，我们可以直接用它作为查询词去匹配article.content，并按相关性排序取最优连接：
SELECT a.id AS article_id, t.id AS tag_id, t.keyword, MATCH(a.content) AGAINST(t.keyword IN NATURAL LANGUAGE MODE) AS relevance FROM article a JOIN tag t ON MATCH(a.content) AGAINST(t.keyword IN NATURAL LANGUAGE MODE) > 0 ORDER BY a.id, relevance DESC;
上面的写法在关联条件里直接使用全文匹配函数，数据库会先计算每个tag对每篇article的相关性，只保留大于零的结果，也就是至少命中一次关键词的组合。因为相关性分数已经隐含了词频权重，所以不需要自己写计数逻辑，就能让出现频次高的关键词自然排在前面。
如果希望显式拿到关键词在文章中出现的次数，可以结合正则表达式或应用层统计，但在纯SQL里更实用的做法是直接信任MATCH返回的分数。对于需要严格词频门槛的场景，可以把relevance换算成近似词频，或者在插入时额外维护一个关键词计数表，用普通索引做二次过滤，从而兼顾精度与性能。
与LIKE及外部脚本方案的对比和选型建议
很多人第一反应是写LIKE '%关键词%'来做关联，但这种方式有致命缺陷。LIKE无法利用普通索引，只能全表扫描，并且它只判断存在性，不区分出现一次还是十次。在关联查询里，若左表十万行、右表一千词，LIKE会产生百亿次字符串匹配，基本不可行。而全文索引通过倒排结构把复杂度降到词项级别，速度可以提升三个数量级。
-- 低效的LIKE模糊连接示例
SELECT a.id, t.id
FROM article a, tag t
WHERE a.content LIKE CONCAT('%', t.keyword, '%');
另一种常见思路是把数据导出到Python或Spark里用分词库算相似度，再回写数据库。这种方法灵活度高，能实现复杂的TF-IDF或神经网络匹配，但引入了额外的管道维护成本和同步延迟。如果业务只要求基于关键词频次的模糊连接，且数据已在关系型数据库内，直接用全文索引是最省事的，避免了系统间搬运。
在选型时，建议先评估数据规模和实时性要求。小于十万行且更新不频繁，LIKE加缓存或许能忍；中等规模且追求简洁，全文索引是首选；只有当你需要语义级模糊、同义词归一或跨语言匹配时，才值得上外部脚本方案。另外，如果数据库版本较老不支持ngram，可以考虑把文本预切成关键词数组存到JSON字段，再配合多值索引做近似频次连接。
实战中的避坑与性能调优
全文索引虽好，但配置不当也会踩坑。比如MySQL的ft_min_word_len参数决定了最小索引词长，中文用ngram时默认token大小为2，如果你关心的是单字频次就要调小。还有事务提交后索引并非实时可见，在高频写入场景要做延迟容忍。曾经有团队发现关联结果漏数据，排查半天才发现是刚插入的记录还没合并进全文索引缓存。
在模糊连接查询里，尽量给MATCH AGAINST加上BOOLEAN MODE来精确控制词频权重。例如'+数据库'表示必须出现，而'数据库*'匹配前缀，配合IN BOOLEAN MODE可以写出类似搜索引擎的查询表达式，让连接逻辑更可控。同时，对大表做全文连接时，先通过普通索引缩小article范围，再在子集上跑MATCH，能大幅降低计算量。
最后提醒，全文索引占用的磁盘空间通常是原文本的百分之三十到一倍不等，且写入时维护开销高于普通索引。如果系统是写多读少且关联不频繁，就不必强行上全文索引。合理的做法是把需要模糊连接的冷数据单独同步到只读实例，建好全文索引做分析，这样既不影响主库写入，又能稳定支撑关键词频次关联需求。
fulltext_index fuzzy_join keyword_frequency修改时间：2026-08-13 20:33:43