Elasticsearch基本用法手把手：实现全文搜索功能

从零开始手把手教你用 Elasticsearch 实现中文全文搜索

你有没有遇到过这样的场景？用户在电商网站输入“华为折叠屏手机”，结果系统要么搜不到相关商品，要么把一堆不相关的“华强北壳子”塞给他。更糟的是，数据库一查就是好几秒——这体验，换我我也直接关掉页面。

传统关系型数据库擅长精确匹配，但面对模糊查询、语义扩展和高性能响应时，就显得力不从心了。这时候，Elasticsearch就该登场了。

它不是数据库的替代品，而是专门为“搜索”而生的引擎。今天我们就抛开那些高大上的术语，用最接地气的方式，带你一步步搭建一个能真正“理解用户意图”的全文搜索系统。

为什么是 Elasticsearch？

先说结论：如果你要做的是内容检索类功能，比如商品搜索、文章查找、日志分析，那 Elasticsearch 几乎是目前最优解之一。

它基于 Lucene 构建，天生为“倒排索引”设计，能在亿级数据中实现百毫秒级别的响应。更重要的是，它支持复杂的布尔逻辑、相关性打分、高亮显示、聚合统计……这些在传统 SQL 里要写一堆 LEFT JOIN 和 LIKE 的操作，在 ES 里一条 JSON 就搞定。

而且它的接口全是 RESTful 风格，不管你后端是 Java、Python 还是 Go，都能轻松调用。

第一步：搞懂两个核心概念 —— Index 和 Mapping

你可以把Index（索引）想象成 MySQL 里的“表”。比如我们做一个商品搜索系统，就可以创建一个叫products的索引。

但别急着往里塞数据，得先定义清楚每个字段怎么处理。这就引出了第二个关键概念：Mapping（映射）。

Mapping 就像是这张“表”的 schema，但它比数据库的约束灵活得多。你可以告诉 ES：“这个字段我要做全文检索”、“那个字段只用来过滤不用分词”。

举个例子：

PUT /products { "mappings": { "properties": { "title": { "type": "text", "analyzer": "ik_max_word", "search_analyzer": "ik_smart" }, "category": { "type": "keyword" }, "price": { "type": "float" }, "create_time": { "type": "date" } } } }

这段代码做了什么？

• 创建了一个名为products的索引；
• 定义了四个字段：标题、分类、价格、创建时间；
• 关键来了：title字段用了"text"类型，并指定了 IK 分词器。

注意这里的两个分词器：
-ik_max_word：索引时尽可能细粒度切词，提高召回率；
-ik_smart：查询时使用粗粒度分词，提升准确率。

什么意思？
比如你输入“智能手机”，IK 会切成[智能, 智能手机, 手机]。这样即使文档里只有“这款手机很智能”，也能被匹配到。

而category用的是keyword，意味着它是精确匹配字段——适合做筛选、聚合，比如“只看电子产品”。

⚠️ 提醒：mapping 一旦设定，字段类型就不能改了！所以生产环境一定要提前规划好。

第二步：让 ES “看得懂中文”——分词器才是灵魂

很多人第一次用 ES 做中文搜索，都会踩同一个坑：默认分词器会把“中国”拆成'中', '国'，然后你搜“中国”反而找不到结果。

这就是因为没配对分词器。

Elasticsearch 默认的standard分词器是为英文设计的，靠空格和标点切词。中文没有空格怎么办？必须上第三方插件 ——IK Analyzer。

如何安装 IK？

很简单，进入你的 ES 安装目录：

./bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v8.11.0/elasticsearch-analysis-ik-8.11.0.zip

版本号请根据你使用的 ES 版本调整。

装完重启 ES，就能用了。

能不能更聪明一点？加个同义词库！

用户搜“iPhone”，你也想让他看到“苹果手机”；搜“轿车”，也能命中“小汽车”。这就要靠自定义 analyzer 了。

先准备一个同义词文件config/analysis/synonym.txt：

iPhone, 苹果手机, Apple手机 轿车, 小汽车, 私家车 折叠屏, 折叠手机, 折叠式屏幕

然后配置索引时引用它：

PUT /news_index { "settings": { "analysis": { "filter": { "my_synonym": { "type": "synonym", "synonyms_path": "analysis/synonym.txt" } }, "analyzer": { "custom_chinese": { "tokenizer": "ik_max_word", "filter": ["lowercase", "my_synonym"] } } } }, "mappings": { "properties": { "content": { "type": "text", "analyzer": "custom_chinese" } } } }

现在，“iPhone”和“苹果手机”就被视为同一个词条了。搜索任何一个，另一个也会被召回。

这才是真正的“语义理解”。

第三步：Query DSL —— 写出像人一样思考的查询

ES 的查询语言叫Query DSL，听起来很高深，其实就是用 JSON 描述你要找什么。

我们来看几个实战中最常用的查询方式。

1. 全文匹配：match 查询

用户输入关键词，你想在标题里找相关内容：

GET /products/_search { "query": { "match": { "title": "华为折叠屏手机" } } }

ES 会自动用你在 mapping 中指定的分词器去解析这句话，然后去倒排索引里找包含这些词的文档。

返回的结果还会带一个_score字段，表示相关性得分。越相关，分数越高，默认按这个排序。

2. 精确筛选：term + filter

你想加个条件：只查“电子数码”类的商品。

GET /products/_search { "query": { "bool": { "must": [ { "match": { "title": "手机" } } ], "filter": [ { "term": { "category": "electronics" } }, { "range": { "price": { "gte": 1000, "lte": 5000 } } } ] } } }

这里用了bool查询：
-must：必须满足，影响评分；
-filter：必须满足，但不影响评分，效率更高。

价格区间也放在filter里，因为它只是筛选条件，不需要参与打分。

3. 多条件组合：should 实现 OR 逻辑

如果用户希望搜“华为或小米的手机”，可以这样写：

"should": [ { "term": { "brand": "huawei" } }, { "term": { "brand": "xiaomi" } } ], "minimum_should_match": 1

should相当于 OR，minimum_should_match控制至少满足几个条件。

实际工作流程演示：一次完整的搜索发生了什么？

假设用户在前端输入：“我想买一台便宜的华为折叠屏手机”

我们的后端服务会怎么做？

1. 接收请求，提取关键词：“华为 折叠屏 手机 便宜”；
2. 构造 query：
   -match查标题是否包含这些词；
   -filter加上：
   • category: electronics
   • price < 8000
   • status: in_stock
3. 发送给 ES；
4. ES 执行过程：
   - 使用ik_smart对查询语句分词 →[华为, 折叠屏, 手机]
   - 在倒排索引中查找包含这些词的文档；
   - 计算 BM25 相关性得分；
   - 应用 filter 条件进一步缩小范围；
   - 返回 top 20 结果，附带高亮片段。
5. 前端展示结果列表，关键词高亮，按相关性排序。

整个过程通常在100ms 内完成，哪怕数据量上千万。

为什么它比数据库 LIKE 快那么多？

我们来对比一下：

根本原因在于底层结构不同：

• 数据库是“正向索引”：每行记录 → 所有字段值；
• ES 是“倒排索引”：每个词 → 包含它的文档列表。

就像查字典 vs 查索引页。你要找“折叠屏”相关的所有商品，ES 根本不用扫全表，直接查“折叠屏”对应的文档 ID 列表就行。

生产环境避坑指南：这些细节决定成败

我在实际项目中踩过的坑，现在都告诉你。

🛑 坑点 1：不分片或乱分片

分片（shard）数量一旦设置就不能改！建议：
- 单个分片控制在10~50GB；
- 初始主分片数 = 预估总数据量 / 单分片上限；
- 比如预计存 200GB 商品数据，可设 5 个主分片。

PUT /products { "settings": { "number_of_shards": 5, "number_of_replicas": 1 }, "mappings": { ... } }

🛑 坑点 2：用错分页方式

千万别这么写：

"from": 9990, "size": 10

这是所谓的“深度分页”，会把前 10000 条都拉出来再截断，非常耗内存。

正确做法：使用search_after

GET /products/_search { "size": 10, "sort": [ { "_score": "desc" }, { "create_time": "desc" } ], "search_after": [0.85, "2024-05-01T10:00:00Z"], "query": { ... } }

通过上一页最后一个文档的排序值定位下一页，性能稳定。

🛑 坑点 3：同步机制太 crude

很多团队直接定时全量导入，导致数据延迟严重。

推荐方案：
- 增量同步：监听 MySQL binlog（可用 Canal 或 Debezium）；
- 或通过 Kafka 中转：业务系统发消息 → Logstash 消费写入 ES；
- 实时性可达秒级。

🔐 安全性和监控也不能少

• 启用 X-Pack Basic 安全模块，设置用户名密码；
• 用 Kibana 看集群健康状态；
• 配合 Prometheus + Alertmanager 做告警，比如磁盘使用率 > 80% 就通知。

总结：什么样的系统适合引入 Elasticsearch？

不是所有项目都需要 ES。但如果你符合以下任一情况，强烈建议考虑：

✅ 有大量文本内容需要检索（如新闻、博客、商品）
✅ 用户期望“模糊搜索”且结果精准
✅ 查询条件复杂，涉及多维度组合筛选
✅ 对响应速度要求高（< 200ms）
✅ 数据增长快，未来可能达千万级以上

掌握 Elasticsearch 的基本用法，本质上是掌握了一种新的数据访问范式 —— 从“我去哪里找这条数据”，变成“我想要什么样的数据”。

当你不再关心数据存在哪张表、哪个字段，而是专注于“如何让用户更快找到他想要的东西”时，你就已经站在了产品体验的更高维度。

最后送大家一句我常说的话：

搜索的本质，不是技术问题，而是理解用户意图的问题。
工具只是桥梁，真正的价值在于你怎么用它连接人心。

如果你正在构建搜索功能，不妨试试从这一条请求开始：

GET /products/_search { "query": { "match": { "title": "你最想卖出去的那个产品名字" } } }

跑通那一刻，你会感受到一种奇妙的成就感 —— 因为你做的不只是代码，而是一个能“听懂人话”的系统。

欢迎在评论区分享你的实践心得，我们一起把搜索做得更智能。