Sunqy 文档库

主题

09 · 搜索引擎（ES）入门与场景 ​

全文搜索、聚合分析、模糊匹配——这些在 MySQL 里会拖垮库的查询，是 ES 的主场。本篇讲清 ES 与关系型的分工边界、核心概念（倒排索引/分片/副本）、以及什么时候该引入。

速览卡 ​

项内容
一句话定位ES 解决"全文检索 + 复杂聚合"，与关系型分工而不是替代
核心内容倒排索引原理、索引/分片/副本概念、与 MySQL 的分工、引入时机
读完能回答为什么 MySQL LIKE 慢而 ES 快？ES 能当主库吗？
相关板块DB01 关系模型 ｜ DB07 NoSQL 选型 ｜ C10 数据建模

一、为什么 MySQL LIKE 慢、ES 快 ​

text
MySQL：LIKE '%关键词%' → 全表扫描，逐行匹配（索引通常用不上）
ES：倒排索引 → 预先把文档拆成词，建立 "词 → 文档列表" 的映射

倒排索引是搜索引擎的核心：不是"文档里有没有这个词"，而是"这个词出现在哪些文档"。

文档 1: "今天天气好"
文档 2: "天气真不错"

倒排表：
天气 → [文档1, 文档2]
今天 → [文档1]
不错 → [文档2]

二、ES 的三个核心概念 ​

概念是什么前端类比
索引（Index）逻辑上的"数据库/表"（文档集合）一张表
文档（Document）一条 JSON 记录一行数据
分片/副本数据水平切分与冗余副本分库分表的思路

注意：ES 的 "index" 跟关系型里的 "索引" 是两个不同概念，别混。

三、ES 与 MySQL 的分工 ​

能力MySQLES
事务、强一致✅ 主库❌ 弱一致
全文检索 / 模糊❌ LIKE 慢✅ 主场景
复杂聚合 / 实时分析⚠️ 会拖库✅ 擅长
精确点查（按 id）✅⚠️ 不如主库

典型架构：MySQL 是事实源（source of truth），ES 是查询副本。 写入走 MySQL，通过 binlog/应用双写同步到 ES，查询走 ES。

四、什么时候该引入 ES ​

信号说明
全文搜索是核心功能商品搜索、文章检索
LIKE 慢且没法优化数据量上来后全扫不可行
需要多字段复杂聚合报表、筛选、统计
模糊/纠错/权重排序搜索体验要求高

反信号（先别上）：

  • 只是简单 WHERE 精确匹配 → 关系型索引就够
  • 数据量小、查询简单 → 引入 ES 是运维负担
  • 强一致是硬需求 → ES 不适合当唯一数据源

五、数据同步：怎么把数据喂给 ES ​

方案机制代价
应用双写写库时同步写 ES双写失败要补偿
binlog 订阅监听 MySQL 变更日志同步基建要求高，最可靠
定时全量重建定期全量导简单，但延迟大

无论哪种，都要有对账/重建机制——ES 和 MySQL 数据不一致是常态，要有兜底任务定期校验。

六、自检清单 ​

  • [ ] 能说出倒排索引为什么快于 LIKE
  • [ ] 知道 ES 的 index/document/分片/副本概念
  • [ ] 知道"MySQL 是事实源、ES 是查询副本"
  • [ ] 知道何时该引入、何时不该引入
  • [ ] 了解双写/binlog 同步与对账兜底

七、常见误区 ​

误区事实
"ES 能当主库"弱一致、无事务，适合查询副本
"ES 的 index 就是 MySQL 索引"是逻辑"表"，概念不同
"ES 很重不要碰"有明确场景时它是最合适的工具
"同步一次就完事"双写会失败，要对账重建
"MySQL LIKE 也够"数据量上来全扫不可行

八、动手练习 ​

练习 A：画倒排索引 ​

给三句话建倒排表，回答"包含'天气'的文档有哪些"。

练习 B：判断该不该上 ES ​

三个场景：商品搜索（支持关键词+筛选+排序）、用户按 id 查询、日志分析聚合。分别判断。

练习 C：设计同步方案 ​

一个订单系统要支持按商品名搜索订单。设计"写库 → ES"的同步链路，并说明失败怎么兜底。

相关文档 ​

本区 ​

其他域 ​