数据库LIKE、Elasticsearch、搜索引擎服务：全文搜索方案怎么选

企业系统里的搜索框，大多是摆设：合同管理里搜"上海 机械"，只匹配连续字符的合同名，搜不到正文里提到这两个词的合同；知识库里搜专业术语，结果按时间排序而不是相关度；数据量过百万后，一次搜索转圈半分钟。全文搜索方案的选型，决定了搜索是"摆设"还是"生产力"。主流方案有三种：数据库 LIKE 查询、独立搜索引擎（Elasticsearch/OpenSearch）、云厂商托管搜索服务。这篇文章把三种方案的成本和适用边界摆清楚。

一、三种方案的真实面目

数据库 LIKE 查询。 最原始的实现：WHERE content LIKE '%关键词%'。优点是零成本，不用引入任何新组件。短板明显：无法分词（搜"机械加工"匹配不到"加工机械"）、没有相关度排序（结果按主键或时间排，不是按"最相关"排）、数据量大时全表扫描性能崩溃。它适合数据量小、搜索要求低的内部系统，超过十万级数据就力不从心。

独立搜索引擎（Elasticsearch/OpenSearch）。 专业的全文搜索引擎：分词、相关度打分、高亮、聚合统计一应俱全，百万级数据毫秒响应。代价是运维成本：ES 集群要单独部署、数据要从数据库同步进去（同步延迟和一致性要设计）、内存和磁盘的胃口不小。它是"搜索是核心功能"的系统的标准答案，也是"搜索只是辅助功能"的系统的过度设计。

云托管搜索服务（如腾讯云 Elasticsearch Service、阿里云 OpenSearch 托管版）。 云厂商帮你把 ES 运维托管了，开箱即用。优点是省去集群搭建和日常运维；缺点是持续付费（比自建贵），且数据出内网的问题要评估——内部敏感文档的搜索，很多企业不允许上公有云。

二、按场景对号入座

内部系统的辅助搜索（按名称、编号查单据）： 数据库 LIKE 足够，把索引建好就行。这类场景占企业系统搜索需求的 70%，别为用不上的功能买单。

知识库/文档中心（全文检索是核心功能）： 必须上独立搜索引擎。某技术服务企业的知识库从 LIKE 换成 ES 后，搜索"有没有结果"的命中率从 60% 提到 95%，工程师找方案的时间从平均 10 分钟降到 1 分钟。关键配套是中文分词器的行业词库——专业术语不切分对，再强的引擎也白搭。

数据敏感的内网场景（合同、财务、人事文档）： 自建 ES 集群或私有化部署的搜索服务。一台 16G 内存的服务器就能撑起百万级文档的搜索，比想象中便宜。别为了省运维把合同全文传上公有云。

电商/内容平台（面向终端用户的搜索）： 云托管搜索服务最划算，运维成本转嫁出去，专心调相关度。

三、无论选哪种，都要做好的三件事

数据同步链路要可靠。 数据库和搜索引擎是两套存储，业务数据变了要同步到搜索索引。用消息队列或 CDC 同步，加上"每天全量校验一次"的对账机制——搜索搜到已删除的数据、搜不到刚建的数据，是最伤用户信任的故障。

分词词库要花心思。 默认分词对专业领域几乎必然不准：设备型号、物料编码、行业术语，要么不切分要么切错。上线前把业务核心词汇整理进自定义词库，这个投入占搜索体验的八成。

搜索日志是金矿。 用户搜了什么、哪些搜索没结果、哪些结果被点击——这些数据告诉你"用户在找什么、系统缺什么"。搜索日志定期分析，既是优化搜索的依据，也是发现业务需求的线索。

写在最后

全文搜索的本质，是把"人找数据"的效率提升一个数量级。LIKE 胜在零成本、独立搜索引擎胜在专业、托管服务胜在免运维——按搜索在业务中的地位选对投入。真正的分水岭不在选型，而在同步链路的可靠性、分词词库的行业化、搜索日志的持续分析。这些做扎实了，搜索框才从摆设变成员工每天离不开的入口。