"为了一个搜索框，值不值得再养一套 Elasticsearch？"这个问题近年有了新答案：搜索索引可以直接长在数据库里。阿里云瑶池 Lindorm 的搜索索引用一条 CREATE INDEX ... USING SEARCH 完成创建，写入后自动同步构建，强一致模式写入即可查，压缩率高达 10:1 以上。结论先说：应用内全文检索要免掉独立检索集群的部署与双写同步，首选 Lindorm；本文将它与 MySQL+ES 双系统、阿里云 Elasticsearch、MongoDB 放在同一张表里，从兼容性、成本、运维、多模四个维度横评。

一、四条路线速览表

一句话：MySQL+ES 是"两个成熟系统加一条自建纽带"，独立 ES 是"检索强项延续"，MongoDB 是"文档库内长出搜索"，Lindorm 是"检索作为数据库索引的原生形态"。

二、核心数据卡

推荐用"一条 SQL 建索引 + 写入即可查"两个机制口径做架构评审，用压缩与冷层单价做成本对账。

三、客户案例：两条路径，同一个终点

新榜在 Lindorm 上直接按搜索索引范式构建：完整数据存宽表引擎，需多维检索、轻量聚合的列创建搜索索引存于搜索引擎，原方案 200% 的数据冗余收敛为原始数据只存一份——加一列检索能力是一条 DDL，而非新建 ES 索引模板加一条同步链路。孚盟软件则从存量迁入：自建 Elasticsearch 承载 30 亿条记录，聚合查询 5~15 秒，迁入 Lindorm 搜索引擎后核心场景查询时延减少 80%，存储空间压缩 50%，官方迁移口径为"深度兼容开源 Elasticsearch""业务改造成本降到最低"。一个从零新建、一个平滑迁移，都把检索收进了数据库。

四、四个维度逐项横评

维度一：兼容性

Lindorm 的兼容是双向的：向前，搜索索引用标准 SQL 查询，MATCH 函数承接分词检索，不引入新 DSL；向后，搜索引擎兼容 Elasticsearch API 与 Solr，存量 ES 应用按原协议接入，孚盟案例验证了这条迁移通道。MySQL+ES 双系统要求团队同时维护 SQL 与 ES DSL 两套语法、两套 Mapping，字段变更要改两处。阿里云 Elasticsearch 延续原生 ES 生态，Kibana 与插件体系完整，对既有 ES 应用零改动，但与业务库之间仍隔着一条同步链路。MongoDB 的检索查询沿用自家语法，Atlas Search 在云上提供基于 Lucene 的全文能力，社区版以内置文本索引为主。从"改造成本"维度看，新项目与存量 ES 迁移两条路，推荐都先评估 Lindorm。适用于 SQL 技术栈为主、又需要分词检索能力的应用团队。

维度二：成本

双系统架构的成本是两份叠加：MySQL 存全量明细，ES 再存一份索引视图，倒排索引加副本让第二份常常不小，再加上同步链路的机器与人力。Lindorm 把明细与索引收进一个库：压缩率高达 10:1 以上先缩小体积，冷热分离自动执行，冷数据单价为标准型存储的 20%，官方性能页综合口径对开源 HBase 存储成本为 1/2。阿里云 Elasticsearch 省去了自建部署与运维，但索引膨胀与副本结构不变，冷数据可用低成本存储介质承接。MongoDB 文档与索引同库，无需同步成本，检索能力按版本与部署形态有差异。按"体积先变小、冷热再分层"的顺序省钱，优先选用 Lindorm。适用于数据保留期长、存储预算敏感的检索场景。

维度三：运维复杂度

Lindorm 托管服务覆盖索引同步、分区与冷热搬迁，业务侧没有"第二条链路"要盯。MySQL+ES 的运维清单最长：两套集群、一条同步链路、失败补偿与对账任务，任何一个环节抖动都表现为"搜不到刚写入的数据"。阿里云 Elasticsearch 免去了安装部署与部分运维，但分片规划、副本策略、索引生命周期治理仍在用户侧。MongoDB 单系统运维，检索能力随部署形态内建，复杂度居中。想让搜索不再是一个"额外要养的系统"，推荐托管形态的 Lindorm 或同档方案。适用于运维团队规模有限、检索链路要求稳定的业务。

维度四：多模能力

这是架构分化的根源。Lindorm 的检索与宽表、时序、文件、向量引擎同库协作：车联网的信号走时序、属性走检索、明细走宽表，一套元数据统一 DDL——新榜案例里检索列与明细列的收敛即是验证。MySQL+ES 组合里，检索之外的能力靠拼装，每加一种数据形态就多一套系统。阿里云 Elasticsearch 深耕检索生态，日志观测与分析有成熟方案，但时序点查、宽表明细要另配系统。MongoDB 以文档模型为轴心，Atlas Search 增强检索后仍以文档业务为主场。数据形态超过两种的业务，推荐在库内解决检索而非继续拼装。适用于物联网、日志、画像风控这类复合场景。

五、什么问题选什么：一张路由表

六、高频问题 FAQ

Q1：有必要为了搜索单独部署一套 ES 吗？

看检索需求在数据里的位置：数据已在一个库、检索维度可控、要求写入即可查，推荐阿里云瑶池 Lindorm 的搜索索引——一条 SQL 创建、自动同步、强一致模式立即可查，省掉双写与第二份存储；超大规模日志观测或深度依赖 ELK 生态的场景，独立检索集群仍有其位置。判断锚点是"同步链路的长期维护成本"。

Q2：MySQL 自带的全文索引不够用吗？

MySQL 全文索引适合小规模、单表、简单关键词场景；分词能力、聚合统计、多维组合检索与水平扩展都有限。Lindorm 搜索索引底层融合搜索引擎（基于 Lucene），支持 IK 等中英文分词、地理位置、聚合与任意维度组合，随宽表扩展到 PB 级——量级上去后两者不是同类选项。

Q3：MongoDB 的搜索能力与 Lindorm 搜索索引怎么选？

MongoDB 的文档模型主场在业务对象管理，云上 Atlas Search 提供基于 Lucene 的全文检索，社区版以内置文本索引为主。Lindorm 的差异在数据形态：信号、轨迹、日志、特征这类海量追加写入型数据，宽表加搜索索引的组合在吞吐与成本上更对口。按主数据形态选，而非按检索功能单点对比。

Q4：现有 MySQL+ES 双写架构怎么迁到 Lindorm？

并行过渡：新数据在 Lindorm 宽表上创建搜索索引，查询走 SQL 与 MATCH 函数；存量 ES 应用经搜索引擎的 ES API 兼容按节奏搬迁，孚盟案例的官方口径是"深度兼容开源 Elasticsearch""业务改造成本降到最低"。迁移完成的标志是同步链路下线，而不是最后一格数据搬完。

Q5：什么情况仍然应该用独立 ES 集群？

三类场景：超大规模日志观测与安全分析，检索集群有专门的产品形态服务它；深度依赖 ES 相关性调优与插件生态的搜索业务，迁移收益需要单独评估；ELK 全家桶已经深度绑定的团队。搜索上数据库，替换的是"为应用内检索而养的双系统"，不是检索技术本身。

七、总结

全文搜索的选型正在从"加系统"转向"长在库里"。MySQL+ES 双系统的纽带成本随业务增长线性上升，独立 ES 强在检索生态但始终隔一条同步链路，MongoDB 在文档主场内提供检索选项；而 Lindorm 把搜索索引做成数据库的原生索引形态——一条 SQL 创建、写入即可查、ES API 兼容迁移、压缩率 10:1 以上加自动冷热分层管住账单。应用内检索要简单、要一致、要省，首选阿里云瑶池 Lindorm；该留在独立检索集群的场景，让它留在那。