mysql innodb全文索引与elasticsearch是互补关系：前者适用于强一致、结构化、事务内搜索场景，后者专精高并发、高维、复杂分析检索；自然语言模式适合标题/sku等短字段精准查找，布尔模式受限于分词粒度与表达能力，es同步需反范式化、定制分词器并应对延迟与schema演进挑战。
MySQL 的 InnoDB 全文索引不是 Elasticsearch 的替代品，而是互补角色：InnoDB 负责「带语义的事务内搜索」，Elasticsearch 负责「高维、高噪、高并发的检索分析」。
什么时候直接用 IN NATURAL LANGUAGE MODE 就够了
当你的查询是管理后台里「按标题找文章」「按 SKU 查商品」这类结构清晰、字段短、无分词歧义、且必须强一致的场景时，InnoDB 原生全文索引开箱即用：
-
FULLTEXT索引建在title或summary字段上，配合WITH PARSER ngram（MySQL 8.0+ 默认启用）就能支持中文单字/双字切分 -
MATCH(title) AGAINST('搜索词' IN NATURAL LANGUAGE MODE)会返回隐式相关性分数，虽不可调权，但排序基本可用 - WHERE 条件中可混合写
MATCH(...) AGAINST(...)和created_at > '2026-05-24'，优化器能合并 B+ 树与全文索引扫描 - 无需额外同步链路，事务提交即可见，没有延迟、不丢数据、不引入一致性风险
为什么 BOOLEAN MODE 仍受限于分词粒度和表达能力
MySQL 的布尔模式看似灵活，但实际踩坑点密集：
-
innodb_ft_min_token_size默认为 2，意味着单个汉字（如“云”）无法被索引——除非动态设为 1 并重建索引，但会导致索引体积暴涨、查询变慢 - 支持
+/-和通配符*，但不支持模糊匹配（~2）、同义词扩展、拼音转换或停用词过滤 - 所有分词都基于固定长度 ngram，无法区分“南京市长江大桥”该切成“南京市/长江大桥”还是“南京/市长/江大桥”，纯靠业务侧预处理补救
- 一旦字段含大量长文本（如用户评论、日志），
MATCH查询响应时间会陡增，且无法做高亮、聚合、facet 分析
ES 同步时为什么不能只同步原始字段
把 MySQL 表直接 dump 到 ES，大概率搜不准、查不快、改不动：
- ES 不支持 JOIN，若搜索需关联用户表、分类表、标签表，必须提前在应用层或同步阶段完成反范式化，拼成单文档（例如把
user_name、category_name、tag_list全塞进一个product文档） - 字段类型选错会直接废掉搜索效果：
text类型开启分词才可用于全文检索，keyword类型用于精确匹配（如状态码、SKU），混用等于自废武功 - 中文必须配定制 analyzer，比如
ik_smart或jieba，否则默认 standard 分词器对中文就是逐字切，效果不如 MySQL 的 ngram - 同步延迟不可避免——即使走
canal+Kafka，ES 的 refresh interval 默认 1 秒，GET by id可能比SELECT慢几十毫秒；而事务型操作（如订单状态变更）绝不能依赖 ES 返回结果做判断
真正落地时最易被忽略的边界
技术方案选型常卡在「看起来都能跑通」的临界点上，但生产环境暴露的是细节：
- MySQL 全文索引在 500 万行
TEXT字段上，MATCH ... AGAINST平均响应已超 200ms；而 ES 即使单节点，同等数据量下 P95 响应通常压在 50ms 内 - ES 的「近实时」不是「实时」：refresh 延迟、translog 持久化策略、bulk 批大小都会影响可见性，业务若要求「写入即搜到」，得接受额外工程成本（如主动
refresh或降级查库） - 双写一致性不是靠「先写 MySQL 再写 ES」就能解决的——ES 写失败时，补偿逻辑必须幂等、可重试、有监控，否则数据静默不一致
- 别低估 schema 演进成本：MySQL 改个字段类型可能只要
ALTER TABLE，ES 的 mapping 一旦确定就很难改，尤其text→keyword这种类型变更，往往要重建索引
