斯迈尔齿科那天下午，同事把一段 SQL 甩到我面前：一张只有 50 万行的商品表，WHERE name LIKE '%无线耳机%'，线上平均耗时 780ms。另一套基于 Elasticsearch 的系统，同样的模糊查询，数据量过亿，响应却稳定在 30ms。他问我，同样是“模糊搜一下”，怎么差距能大到这种程度？
这个问题其实问到了点子上。MySQL 的 LIKE 和 Elasticsearch 的“模糊搜索”表面上看起来干的是同一件事，但底层结构从设计那天起就走上了完全不同的两条路。这篇文章我不打算讲太玄的理论，就从一个开发者的实际视角出发，拆一下 LIKE 到底慢在哪、ES 到底快在哪，然后聊聊工程上什么时候该用什么，以及替换过程中的那些坑。适合正在纠结“要不要上 ES”的团队，也适合准备数据库和搜索相关面试的人当成一篇备料。
1. 一条慢了 800ms 的 SQL：MySQL LIKE 的代价到底去哪了
1.1 最容易踩的误区：以为加个索引就完了
先看一个最常见的情况。很多业务里产品提了个需求：“搜索框里输入关键词，能匹配商品名称就行。”开发第一反应就是：给 name 字段加个普通索引，然后 WHERE name LIKE '%关键词%'。结果测试一看，索引建了，速度还是很慢。再看执行计划，type 那一栏写的既不是 ref，也不是 range，而是毫不留情的 ALL——全表扫描。
这不是 DBA 没给你建索引，而是 SQL 写法本身把索引废掉了。MySQL 的 B+ 树索引有一个基本规则：它只能高效匹配前缀。也就是说 LIKE '无线%' 是可以走索引的，因为从第一个字符开始，索引就能按顺序定位。但一旦你在前面加了百分号，变成 LIKE '%无线%'，优化器就傻了：它不知道第一个字符是谁，自然也不知道该从索引的哪个位置开始找。你让它怎么用 B+ 树？只能从头到尾把所有叶子节点过一遍。这就是为什么你明明加了索引，执行计划还是给了 ALL。
简单理解，B+ 树索引就像一本按拼音排好序的电话簿。LIKE '张%' 等于翻到“张”那一页，往后顺序读就行了，很快。LIKE '%张%' 就像有人问你“名字里带张的人都有谁”，你不可能跳过任何一页，因为每个名字中间都可能藏着“张”。唯一的办法是老老实实把整本电话簿从头翻到尾，一页一页看。
1.2 全表扫描的真正成本：不是 CPU，是磁盘 IO
很多人以为全表扫描慢是因为数据多、CPU 算不过来。其实对 MySQL 来说，最大的瓶颈在磁盘 IO。50 万行数据量听着不大，但每一行包含的字段可能很多——名称、描述、价格、图片 URL、上下架状态、创建时间……这些数据分散存储在每一个数据页里。全表扫描意味着 InnoDB 要把所有数据页从磁盘读进内存，再逐行做 LIKE 的模式匹配。
这里有个隐藏得很深的点：就算数据总量只有 500MB，但如果你查询只需要匹配 name 字段，这 500MB 里 90% 以上的字节其实是根本不需要的无用数据（比如图片链接、富文本描述），但全表扫描没办法只读 name 列，它把整行都拉进来了。这就是我常和同事说的“读得太多、用得很少”的浪费。SQL 慢的本质往往是 IO 放大，而不是匹配本身要花多少 CPU。
下边这个表是我在自己的测试环境里跑出来的大致数据，大家感受下趋势：
| 数据量 | LIKE '%关键词%' 耗时（无索引） | LIKE '关键词%' 耗时（有索引） | 数据页扫描量 |
|---|---|---|---|
| 5 万行 | 180ms | 3ms | 400+ |
| 50 万行 | 780ms | 6ms | 3800+ |
| 500 万行 | 无法预估（分钟级起步） | 15ms | 40000+ |
注意最后那行。数据量从 50 万涨到 500 万，LIKE '关键词%' 因为走索引，时间只从 6ms 涨到 15ms；但 LIKE '%关键词%' 是灾难级的增长，因为数据页数量线性增长，扫描时间几乎也是线性涨的。到了千万级，这种查询在 OLTP 线上环境基本就是“定时炸弹”，很可能把数据库的 IO 打满，拖垮其他正常请求。
1.3 那 LIKE 加索引就彻底没救了吗？也不全是
这里插一个很多人不知道的细节。如果业务上确实需要在 MySQL 里做模糊搜索，而搜索量又没那么大，有两个方案可以救急：
第一个方案是“覆盖索引”。既然全表扫描慢是因为读了太多无关列，那我就让查询的数据尽可能都在索引里。比如你可以建一个 idx_name(name,id) 或联合索引，然后查询时只 SELECT id FROM table WHERE name LIKE '%关键词%'。MySQL 在 InnoDB 里可以通过索引覆盖扫描减少回表次数，虽然还是要扫索引，但索引体积远小于全表，速度会有明显提升。
第二个方案是“反向 LIKE”。如果业务搜索场景是“以 xxx 结尾”，比如搜索文件名后缀，你可以把数据冗余一份倒过来的字符串，然后查到 LIKE '后缀逆序%' 再逆回去。这个思路在数据量不大、模式相对固定的场景下能救命，但通用性很差。
但从本质上说，这两个方案都是“对症不对因”。因为 MySQL 的 B+ 树索引结构天生就不是为任意位置的子串匹配设计的。真正的解法还是要回到搜索引擎的思路——倒排索引。这就是 ES 快如闪电的第一个核心原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ES 为什么快：倒排索引把“扫描”变成了“查字典”
2.1 一个比喻搞懂倒排索引
先做个对比。想象你在图书馆找一本包含“代码整洁之道”这句话的书。MySQL 的做法是跑到书架前，从第一本开始，一本一本地翻，看每本书里有没有这句话，翻完整个图书馆你才知道结果。而 ES 的做法是：图书管理员手里有一本巨大的目录，上面写着“代码”这个词出现在哪些书的第几页，“整洁”出现在哪些书的第几页。你只要查目录，立刻拿到一个“出现文档清单”，然后根据清单去取书就行。
那本“目录”就是倒排索引。它的核心结构是：词项（Term） → 包含这个词项的文档列表（Posting List）。你输入一个查询词，ES 只需要去字典里找到这个词项，然后拉出对应的文档 ID 列表，再去取文档内容。整个过程不需要遍历任何一篇文章，跟总数据量几乎无关，所以才能做到亿级数据还能几十毫秒返回。
2.2 从 text 到 keyword：ES 里的“模糊”不止一种
这里有个高频误解：很多人一上来就在 ES 里用 wildcard 查询，然后抱怨说 ES 也不快。这是把“搜索引擎的模糊”和 MySQL 的 LIKE 混为一谈了。
ES 真正快的模糊，是全文检索，依赖的是分词器（Analyzer）。比如还是那句话，“商品名称：无线蓝牙耳机”，ES 会先经过分词器把它拆成“无线”“蓝牙”“耳机”这样的词项，然后在倒排索引里分别建立词项到文档的映射。查询时，你输入“无线耳机”，query 也会被分词成“无线”和“耳机”，然后分别查倒排索引，取交集。整个过程是对词项的精确查找，而不是子串的暴力匹配。在这种模式下，它解决的是“哪些文档里包含哪些词”的语义匹配问题，这也才是 ES 的看家本领。
但如果你在 ES 里用 wildcard 做 *无线耳机* 这种模糊查询，那么抱歉，它同样会扫描该字段的所有词项，性能退化得很厉害。如果你用 regexp 查询，那更是重量级操作。所以，正确的认知是：ES 快，指的是词级别的匹配，靠的是建立良好的分词索引；如果你仍然把它当数据库做子串扫描，那 ES 同样会翻车。这一点，下面会结合具体实操再展开。
2.3 ES 一次查询请求内部做了什么
再往深一层看 ES 的查询链路。客户端发来一个 match 查询请求：
json复制{
"query": {
"match": {
"name": "无线 耳机"
}
}
}
ES 收到请求后，协调节点（coordinating node）会把请求广播到目标分片的每个分片副本（或主分片），每个分片独立执行查询——先在本地倒排索引中找到“无线”和“耳机”两个词项对应的 posting list，再做合并，算出文档得分，取回文档 ID，然后根据 from/size 排序后返回给协调节点。协调节点最后把所有分片的结果合并、再排序，返回最终命中列表。整个过程是分布式并行执行的，数据分片越多（合理范围内），单分片需要处理的数据量越小，所以它才能扛住亿级数据量的检索压力。
这里还有另一个容易被忽略的加速器：ES 在倒排索引之外，还维护了一套 Doc Values 正排结构，用于排序和聚合。因为 ES 是按列存储的方式来组织 Doc Values 的，所以当你做 ORDER BY price 或者 range 过滤后排序时，它能直接从列式存储中加载需要的列，不需要像 MySQL 那样回表读取整行数据。这种存储设计上的差异，让 ES 在复杂查询场景下占了很大的便宜。
3. 快到飞起的背后：ES 的“代价清单”与真实权衡
3.1 写入路径：为了查询快，ES 做的事比你想象的复杂得多
如果只有倒排索引长得聪明，ES 还不至于让无数团队又爱又恨——它的快是拿写入延迟、存储开销和集群运维复杂度换的。现实中没有人只问读取性能，大家还得评估写入链路盘不盘得动。
你在 MySQL 里插入一行，InnoDB 直接把记录写到 redo log 和缓冲池的数据页，后续异步刷盘；但在 ES 里，一个新文档要经过好几道关卡才能变成可查询状态：
- 分词与索引构建：文档被写入时，分词器需要对 text 字段实时拆词，然后生成倒排索引项，写进内存 buffer。
- refresh 周期：ES 默认 1 秒执行一次 refresh，把 buffer 中的数据生成一个可查询的 segment。这就是为什么 ES 有“近实时”的特性——你刚写入的数据，默认情况下要等最多 1 秒才能被搜到。
- translog 保证：在事务日志里记录操作，防止机器宕机丢数据。
- segment 合并：随着写入不断增多，磁盘里会积累很多小 segment，后台需要持续做 merge，把小的合并成大的。这个 merge 极其消耗 IO 和 CPU。
这些路径走完，你才能拿到“写入近实时 + 查询毫秒级”的效果。如果你拿 ES 当数据库用，要求实时性特别高（比如写后立刻要读）、还要求强一致性，那这套设计会让你别扭到怀疑人生。
有个很经典的数据对比能说明问题。同样一条记录，MySQL 写入延迟可以稳定在 1ms 以内；ES 即便做了批量写入，想达到高吞吐也需要调大批次、调大 refresh 间隔、合理规划分片数。而一旦集群规模上来，节点多、分片多、副本多，监控、调优、故障恢复又是一个全新的复杂度池子。
3.2 存储成本：搜索快不是免费的
另一个很少有人提的是存储成本。MySQL 里同样字段，存的是原始字符串，多少字节就是多少字节。ES 则要额外存很多东西：倒排索引本身、词项字典、Doc Values 列存、如果开了 _source，还得存一份原始文档 JSON。这意味着在同样业务数据量下，ES 的存储占用通常是 MySQL 的好几倍到十几倍。如果你的业务数据有几十 GB，ES 可能直接吃掉几百 GB 的磁盘，这对小团队来说是个真金白银的成本压力。
我当时接过一个项目，上线之前以为 ES 就是个“好用的索引”，没想到我们只存了 3 个月的日志，ES 集群三节点每台 1TB 硬盘就亮起了空间告警。后来只好加了生命周期管理（ILM），把超过 7 天的索引自动删掉/归档到冷存储，才把磁盘压力控制住。所以在设计阶段，假如你的团队没有专职 ES 运维，一定要提前按“原始数据量 × 冗余系数 10~15”来估算成本，否则后面扩容会非常被动。
3.3 别忽略 filter 与 must 的性能差异
既然说到了 ES 查询优化，这里必须提一个热搜里也反复出现的知识点：filter 和 must 的区别。这也是面试官比较爱问的一个点。
在 ES 的 bool 查询里，must 表示“必须匹配”，它参与相关度评分，会产生 _score；而 filter 表示“必须过滤”，但不参与评分。听起来只是计算方式不同，但性能上差异很关键：filter 的结果会被 ES 自动缓存（使用 Query Cache），如果某类过滤条件反复出现，直接命中缓存，查询性能会有量级提升。
有一个合理场景可以说明：搜索“无线耳机”时，如果你只关心“上架状态=1、价格<500”这样的硬性过滤条件，这些条件就没必要放在 must 里。写成：
json复制{
"query": {
"bool": {
"must": [
{ "match": { "name": "无线 耳机" } }
],
"filter": [
{ "term": { "status": 1 } },
{ "range": { "price": { "lt": 500 } } }
]
}
}
}
这样“滤波条件”能享受缓存，而 match 部分又不会因为额外条件干扰评分排序。很多刚接触 ES 的人把业务里的所有条件一股脑塞进 must，既影响性能又让相关性评分乱成一团，实在不值得。如果你在实际项目里还分不清何时用 must、何时用 should、何时用 filter，最简单的判断标准就是：不参与相关度排序的硬条件全部放进 filter，需要影响排序的打分条件才放 must。
4. 工程落地：到底什么时候该继续用 MySQL LIKE，什么时候必须换 ES
4.1 先把 MySQL 的优化空间榨干
工程上最忌讳的不是选错技术，而是还没把已有技术用明白就盲目引入新组件。我觉得这件事上，ES 不是“银弹”，尤其对于只有几百 MB、几十万行数据的小系统，MySQL LIKE + 合理的缓存可能已经能撑住。你先要审视几个问题：
第一，能不能用前缀匹配？ 如果业务允许做“前缀搜索”，比如用户输入关键词时其实默认从名称开头开始匹配，那尽量把 % 放在后面，让它走 B+ 树索引。你只需要在代码里做一次 LIKE CONCAT('关键词', '%') 就能利用索引。实测结果差别非常显著：同样是 100 万行数据，前缀 LIKE 走索引只要几毫秒，%关键词% 可能要几秒钟。
第二，能不能减少扫描范围？ 比如商品表里加个 category 条件，WHERE category = 3 AND name LIKE '%无线耳机%'，虽然 LIKE 部分还是全表扫，但扫描范围已经被 category 的索引大幅缩小，最后要匹配的行数少了一个数量级。这是最简单也最容易见效的优化手法：不要只知道在 name 上加索引，还要看有没有其他条件能帮 InnoDB 缩小查找范围。
第三，数据量能不能归档？ 如果全表 500 万行，其中 400 万行是 3 年前的历史数据，业务根本不会搜，那么可以把历史数据归档到独立表或冷存储，线上只保留近一年数据。这样 MySQL LIKE 扫描的数据量直接少一个量级，很多时候根本不需要上 ES。
做完这三件事，你会发现大量业务根本不需要新组件，问题就被绕过去了。
4.2 什么信号出现时，才应该认真考虑 ES
如果 MySQL 已经全量走到“最优化”但依然扛不住，通常会出现几个现实信号：
- 数据量到千万级以上，且查询模式必须包含
%关键词%这种任意位置的模糊匹配。 - 业务对“响应时间”敏感，要求查询必须在 200ms 以内完成。
- 搜索条件复杂，除了模糊匹配还要做聚合、多条件过滤、排序，比如价格区间 + 品牌筛选 + 评分排序 + 关键词匹配叠加。
- 期望支持“相关度排序”，比如某个词出现的频率越高越靠前，而不是仅靠时间倒序。
一旦这些信号出现，MySQL LIKE 的能力边界就触顶了。你再堆硬件也只是延缓，而不是解决。这时可以引 ES 进来，但要记住它不是用来替代 MySQL 的，而是专门负责“检索”这一件事。我们通常的做法是：MySQL 继续作为数据主库，负责事务性写入；每次写入数据后，通过消息队列或者增量同步工具把数据变更推给 ES，ES 专门承担查询和搜索请求。这就是典型的“双写/异步同步”架构，也是以 Elasticsearch 为核心引擎的标准姿势。团队里如果已有同步工具或者日志采集组件（比如 Logstash、Flink CDC、DataX 等），引入成本会小很多。
4.3 ES 里做模糊查询：从 match 到 wildcard 的选择
我在最初接触 ES 的时候踩过一个坑，后来才通过实践摸清了不同模糊查询的类型、选择和场景。这里把实战结论写一下：
| 查询类型 | 适用场景 | 性能表现 | 推荐程度 |
|---|---|---|---|
match |
分词后的全文搜索 | 快，走倒排索引 | 首选 |
match_phrase |
要求词序相邻、连续匹配 | 中等 | 需要短句精确匹配时使用 |
prefix 查询 |
前缀通配搜索，比如“无”匹配所有以无开头的词项 | 快于 wildcard，依赖字段的索引方式 | 可用，但注意区分字段类型 |
wildcard 查询 |
任意位置的 * 通配，接近 MySQL LIKE '%...%' |
慢，因为要遍历字段的词项或对源文本做正则扫描 | 尽量不用，数据量小的情况下还能忍 |
ngram 分词 |
通过预处理把“无线耳机”切成多个子串再建索引 | 初次性能好，索引膨胀明显 | 有专门子串搜索需求时首选的设计方案 |
所以在 ES 中“做模糊查询”并不是照搬 SQL 写法，真正要做的是利用分词机制把模糊问题转化成倒排问题。例如想让“无线耳机”能被“线耳”搜到，你可以给 name 字段加一个 edge_ngram 或 ngram 分词器，对“无线耳机”生成“无、无线、线耳、耳机”等子串词项。查询时，输入也被同样切分，然后走 match 查倒排索引，这样就拿回了“快如闪电”的效果。代价是索引体积会变大，因为本来一个词项变成了 N 个子串，这里需要由业务根据搜索规模权衡做取舍。
很多人一上来就喊"ES 的 wildcard 也很慢，根本不快"，本质上还是把 ES 当成普通数据库在使用。没有针对字段设计好分词规则，没有利用倒排索引的核心优势，当然不能发挥它的威力。
5. 实际运维中常踩的坑与问题排查经验
5.1 我见过最典型的三种误判
误判一：给 name 字段加完索引就觉得 LIKE 无解，直接宣布“必须上 ES”。 其实很多团队把 MySQL LIKE 当万金油用，真正的核心问题在于：查询没有走前缀、联合索引没有设计好、数据没有归档。排查顺序应该先是 SQL 层面的优化，再考虑是否引入新组件。我在实际项目中遇到过 500 万行数据的后台列表搜索，SQL 加了一组联合索引，又把查询改成先用 eq 过滤再用 LIKE 尾码，性能直接从 2s 降到 300ms。后来也只是因为管理层要求继续加功能，才逐步引入 ES 承接更复杂的全文检索，而不是一步到位推翻 MySQL。
误判二：只知道“ES 里有模糊查询”，选错查询类型，导致比 MySQL 还慢。 wildcard、regexp 在 ES 里属于高开销操作，尤其在关键字前置用了 * 的情况下，不管是 MySQL 还是 ES，都会触发数据全量扫描。能避免就避免，尽量用基于词项和分词器的 match 查询，让倒排索引发挥价值。
误判三：把 ES 当成 MySQL 的替代品写入事实数据，又没有处理一致性的方案。 ES 最终一致 + 近实时的特点，会让强一致性的写入和读己之写场景变得非常变扭。如果业务里大量出现“我写完了立刻读、必须读到”，那这套架构要花很多精力处理，踩坑的概率极高。
5.2 如果已经上了 ES，线上排查的几个着手点
ES 集群变慢了，先看什么？我来分享一套排查顺序，这也是实践后总结出来的常用思路：
- 先看 CPU 和 IO：如果 CPU 打满，先看是不是频繁有
wildcard、regexp查询或者大分页from+size导致的深分页代价。深分页越深，协调节点需要合并的数据量越大，很伤。 - 再看 segment 数量：如果 segment 数很高，说明 merge 跟不上写入节奏，表现为写入变慢、查询也受影响。这时调大
index.merge.scheduler.max_thread_count或降低写入频率，让 merge 能赶上来。 - 看查询缓存命中率：如果大量使用
filter却没有命中缓存，说明相同条件太少，这时要检查查询模式是否稳定、有没有把本来应属于 filter 范围的条件写进了 must。 - 结合
_search慢日志：开启慢日志以后能看到每一个查询耗时在哪段，可以快速定位是检索阶段还是 fetch 阶段耗时高。fetch 阶段耗时高说明命中的文档太多或者返回字段太大，需要加上_source字段裁剪、翻页改 search_after。
每次排查完我都喜欢做个小沙盘推演，这个习惯也建议大家养成：想象一个查询请求过来，从协调节点分发、各分片执行、合并排序、取回文档、再返回，哪一步最耗时，就在哪一步上做优化。
5.3 一个常用的“混合架构”基线方案
很多团队最终稳定下来的方案，其实既不是纯 MySQL LIKE，也不是纯 ES，而是一个清晰的分层策略。
我带着团队做过一个比较典型的小型电商搜索模块，形态大概是：
- 事务操作与强一致数据继续放在 MySQL，例如订单、库存、用户信息等核心账目。
- 商品搜索单独铺一套 ES 集群，应用写入商品时走 MQ 异步同步到 ES，ES 只承载查询和聚合。
- 商品名称搜索就靠“分词器 + match 查询 + filter 过滤 + 评分排序”，避免使用 wildcard。
- 部分场景（比如订单编号查询、唯一流水号查询）还在 MySQL，但全部走唯一索引或前缀 LIKE，不动摇 MySQL 的命根子。
这套方案的收益很明显：MySQL 的查询压力被削掉了 80%，事务能力不受影响；ES 负责的是最终一致、可容忍近实时延迟的检索场景；两组组件各司其职，不互相当“冤家”。
6. 结合实践经验：从“慢 LIKE”到“快搜索”设计时需要注意的盲点
6.1 数据同步链路最容易出的幺蛾子
很多团队引入 ES 以后，第一个崩溃点不是查询本身，而是 MySQL 到 ES 的数据同步环节。最初我们用定时任务每分钟把修改过的数据全量刷到 ES，结果数据量一大，定时任务跟用户高峰重叠，把原本就紧张的 MySQL IO 彻底打满，线上查询全挂。痛定思痛之后才转向 binlog 监听 + MQ 异步消费 的增量同步方案：MySQL 里发生的每次数据变更都通过监听 binlog 转换成消息，投递到 MQ，再由消费者写入 ES。优点是实时性高，又没有定时全量扫描的压力。
但要注意，全量重建索引这种操作依然无法完全避免，比如 ES 的 mapping 被改过、分词器变化、或者数据同步出现漏消息导致一致性错乱。我建议直接把“重建索引脚本”纳入运维工具集，真出了问题快速跑一遍，比在线上手工排查快得多。
6.2 ID 统一与主键策略
另一个容易被忽略的坑是：ES 文档的 _id 怎么定。很多系统 MySQL 自增主键，如果直接拿自增 ID 作为 ES 文档 ID，后续业务恢复全量重建索引会重复插入没问题，ES 用同一 ID 会直接覆盖，幂等性够强，这点其实是安全的。但有些系统使用业务键（比如用户ID、订单号），要特别注意多个索引复用 ID 会不会冲突、跨索引查询会不会相互干扰。最好的实践是给 _id 定义一个能唯一标识一条业务记录的稳定键（如 userId + '-' + 业务类型），避免意外冲突。
6.3 ES 聚合和排序的分页问题
最后提醒一个经典踩坑：ES 的 from + size 深分页，这也是面试题高频考点。如果你的业务有“第 100 页”这种需求，且每页 10 条，ES 协调节点默认要把所有分片上的前 1000 条都拿到手再归并排序，然后再丢弃前 990 条。这个操作在分页很深的场景下非常消耗内存和 CPU，严重时直接 OOM。正确的姿势是用 search_after 做“翻页”，每次基于上一页最后一条记录的一个唯一排序值继续往后取，代价低、响应快。如果业务必须支持随机跳页，那就需要提前想清楚是否接受大 result window 的代价，或者让前端限制最大翻页深度。
MySQL LIMIT 100000, 10 也有同样的深分页问题，本质上都是“要把前面的记录都翻过去才能拿到目标页”，这个思路其实是相通的。
7. 写在最后的个人体会
做了这么多数据库和搜索相关的优化，我逐渐形成一套自己的决策心法：对一个查询慢的问题，不要第一个念头就是“换技术栈”，而是先问自己三个问题——SQL 写法到底有没有把索引用对，数据是不是该归档的没归档，系统是不是在硬扛它不该扛的查询模式。大多数团队在 MySQL LIKE 场景下面临的痛，真实根源并不是 MySQL “太弱”，而是对索引结构和查询模式的理解有欠缺。
ES 确实很快，但它的快是查询场景的深度优化赢来的，用倒排索引换取了跳过大面积扫描的能力，用分词器把“模糊”变成了“精确查找”。理解到这一层，再看 MySQL 的 LIKE 和 ES 的 match，心里就比较透彻了——它们根本不是同一个物种，一个是数据库顺手做的字符串匹配能力，另一个是为搜索而生的专用引擎。
如果在面试中被问到这类问题，你不妨多走一步：从数据结构讲到查询计划，从 B+ 树讲到倒排索引，从倒排索引讲到分词，再从分词讲到缓存、评分、脏数据、数据同步链路。能讲清楚这些的人，通常已经不是在背八股，而是真的在项目里踩过这些坑，也就能靠这套方法论在真实业务中做出合适的技术选型了。