Full-Text Search选型：选专用搜索引擎(SOLR/Elastic)还是RDBMS内置FTS？

针对你提出的具体场景的选型结论 #

你需要实现拼写容错模糊搜索、同义词、词干提取、自定义相关性与排序规则这几个需求的场景下，Apache Solr/Elasticsearch这类专用全文搜索引擎的优势远大于MySQL FTS，MySQL FTS的能力完全无法满足需求，强行使用反而会带来更高的开发和维护成本。

两者的核心能力差异对比如下：

• 拼写容错能力：MySQL FTS仅支持基础的通配符、ngram近似匹配，无法实现基于编辑距离的智能拼写纠错，也不能结合业务词库做容错召回；Solr原生支持fuzzy查询，可自定义编辑距离阈值，还可搭配拼写检查组件直接返回纠错候选词，不需要额外开发自定义逻辑。
• 同义词、词干提取能力：MySQL FTS的同义词仅支持静态配置文件加载，无法热更新，词干提取仅支持少量语言，自定义扩展能力极弱；Solr可在分词链中自由配置同义词过滤器、词干提取过滤器，支持热更新词库，还可针对不同字段配置独立的分词规则，适配各类业务和多语言需求。
• 自定义相关性与排序能力：MySQL FTS的相关性计算仅支持内置的TF-IDF变种，可调参数极少，几乎无法实现自定义加权规则，比如要给标题字段匹配权重设为内容字段的5倍、叠加商品销量/用户评分等业务数据计算相关性这类需求，用MySQL FTS实现复杂度极高，还会导致查询性能大幅下降；Solr原生支持灵活的字段加权配置，还可通过函数查询自定义相关性计算公式，完全满足各类自定义排序需求。

专用全文搜索引擎热度持续增长的核心原因 #

你提到的三点猜测完全符合实际落地情况，除此之外还有几个业务场景下的核心优势：

• 大数据量下的性能差距极其明显：十万级以内的小数据量下，两者性能差距不明显，一旦到百万级以上的文档量，尤其是涉及多条件组合检索、关联聚合的场景，Solr的查询速度是MySQL FTS的数倍到数十倍。且Solr原生支持分布式扩容，上亿级文档量下只需新增节点即可线性提升性能，MySQL单库碰到性能瓶颈后只能做分库分表，实现复杂度极高。
• 原生覆盖绝大多数检索需求：除了分面搜索、多语言支持之外，Solr还原生支持检索结果高亮、搜索联想建议、地理空间检索、跨字段联合检索等常见的全文检索功能，这些需求用MySQL FTS实现要么需要编写大量额外业务代码，要么根本无法实现，整体开发成本远高于引入Solr的成本。
• 长期运维成本更低：很多人误以为引入Solr会带来额外运维成本，但实际上当检索需求复杂度上升后，MySQL FTS的各种hack优化带来的运维成本更高：比如为了提升检索性能创建的冗余索引会拖慢写入速度，复杂的检索SQL很难优化，慢查询排查成本极高。而Solr的监控、扩容、备份都有成熟的标准化方案，只要做好数据同步逻辑，长期运维成本反而更低。

MySQL FTS的适用场景 #

当然不是所有场景都需要引入专用搜索引擎，如果你的需求同时符合以下所有条件，选择MySQL FTS完全够用：

• 数据量低于100万条，需要检索的字段少于3个
• 仅需要基础的关键词匹配，不需要拼写纠错、同义词、自定义相关性等高级功能
• 检索并发量很低，不需要考虑高可用、水平扩容需求

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