## 概述

很多刚接触 ES 的同学会把索引直接类比成 MySQL 表，初期入门可以，但不能当成准确映射。本文从最小数据单元文档讲起，说明 `_id`、`_source`、`_version` 等元字段，以及文档“不可变更新”的本质：更新不是原地修改，而是标记旧文档删除并新增版本，后台段合并时才真正清理。接着梳理索引作为逻辑命名空间、ES7 后 Type 被彻底移除、分片是 ES 最小读写单元且主分片创建后不能修改、副本用于容灾和分担查询压力。最后介绍 master、data、ingest、coordinating 节点角色，并强调生产环境建议分离 master 与 data 节点。适合后端开发系统建立 ES 基础概念，避免把 ES 简单当表用。

### 一、基础概念：索引、文档、类型、分片、副本

很多刚接触 ES 的同学会直接把 ES 的索引等价理解成 MySQL 的表，这个类比**初期可以用来入门，但不能当成准确映射**，后面会单独对比 MySQL 和 ES 差异。
#### 1、文档（Document）

ES 中最小的数据单元，一条数据就是一个文档，格式是 JSON。
- 唯一标识：`_id`，可以自己指定，也可以 ES 自动生成
- 元字段：`_index`（所属索引）、`_source`（原始 JSON 数据）、`_version`（版本号，旧版本用于乐观锁）、`_score`（相关性打分）
- 文档是不可变的：更新不是原地修改，是标记旧文档为删除，新增一条新版本文档，后台段合并时才真正清理旧数据。

示例文档：
```json
{
  "_id": "1001",
  "_source": {
    "title": "Elasticsearch技术博客",
    "content": "倒排索引原理讲解",
    "author": "stark张宇",
    "create_time": "2026-10-27"
  }
}
```

#### 2、索引（Index）

一类文档的集合，逻辑命名空间，比如`article`、`goods`。
>ES7.0 之后，**Type 类型被彻底移除**，一个索引下直接存放文档，不再支持多 type。ES6 只是兼容过渡，新项目一律不要使用 type。

#### 3、分片（Shard）

索引会被拆分成多个主分片（Primary Shard），分散在集群不同节点上，实现**水平扩容**。
- 主分片数量：**创建索引时确定，创建后不能修改**（只能重建索引 reindex）
- 作用：分布式存储、并行检索；分片是 ES 最小的读写单元，一个分片本质上就是一个独立的 Lucene 索引

#### 4、副本（Replica Shard）

主分片的拷贝，副本分片不能和主分片放在同一个节点。
- 作用：故障容灾（主分片节点宕机，副本可提升为主分片）、分担查询压力，读请求可以走副本
- 副本数量可以动态调整
- 写入流程：先写主分片成功，再同步副本，全部成功才返回 ack

#### 5、节点（Node）

启动一个 ES 进程就是一个节点，节点有角色区分：
- **master 候选节点**：参与 master 选举，维护集群元数据（索引、分片分配信息）
- **data 节点**：存放分片数据，负责数据读写、检索、聚合（业务最常用）
- **ingest 节点**：预处理管道，写入前做数据加工
- **coordinating 节点**：协调节点，接收客户端请求，路由分片，聚合分片结果，所有节点默认都具备协调节点能力

>最佳实践：生产环境建议**分离 master 节点和 data 节点**，避免大查询、大写入打满节点，影响集群元数据稳定性。

### 二、倒排索引原理（ES 底层核心）

想了解倒排索引，就要先知道什么是正排索引， ES 基于 Lucene，核心是**倒排索引（Inverted Index）**，也是全文检索的基石。
#### 1、正排索引

文档 ID → 文档内容，如果要查包含 “后端” 的文档，需要逐篇扫描所有文档，也就是全表扫描，数据量大的时候性能极差。
```bash
doc1：我爱后端开发
doc2：后端开发很香
doc3：我爱Go语言
```

#### 2、倒排索引

先对文档分词，构建【词条（Term）→ 文档列表】的映射表：

|Term（词条）|文档ID列表|
|:-:|:-:|
|我|doc1、doc3|
|爱|doc1、doc3|
|后端|doc1、doc2|
|开发|doc1、doc2|
|很香|doc2|
|Go|doc3|
|语言|doc3|
当搜索关键词`后端`时，直接查表拿到 doc1、doc2，不需要遍历全部文档。
#### 3、倒排索引的附加结构（不止 term+docId）

真实 Lucene 倒排索引包含三部分：
1. **Term Dictionary**：词条字典，所有分词后的 term 有序存储
2. **Term Index**：词条字典的索引，类似 B 树，加速 term 查找，存在内存里
3. Posting List（倒排表）：term 对应的文档列表，里面除了 docId，还存储：
	- TF（词频）：词条在当前文档出现多少次，影响相关性打分
	- DF（文档频率）：有多少文档包含这个词条，用于 IDF 计算
	- 位置信息（position）：词在文档中的偏移，用于短语匹配、高亮
	- 偏移量（offset）：用于搜索高亮

#### 4、段（Segment）机制，非常关键

Lucene 不是实时写入索引：
- 新写入文档先放在内存缓冲区（IndexBuffer）
- 刷盘（flush）生成一个只读的 Segment（小段索引文件）
- Segment 一旦生成，**不可修改**，删除文档只是在`.del`文件打删除标记
- 后台线程定期执行**段合并（Segment Merge）**：把多个小 segment 合并成大 segment，清理标记删除的文档，减少文件数量，提升查询性能
- 近实时 NRT：ES 的 refresh 机制，默认 1s 刷新，把内存 segment 打开供检索，所以 ES 不是严格实时，是近实时搜索

>面试高频：为什么 ES 删除文档不会立刻释放磁盘？为什么段合并会消耗 CPU 和 IO？根源就在 Segment 只读设计。

### 三、分词（Analyzer）

分词器是全文检索的前置，一句话：**把文本字符串切分成词条 term，同时做标准化处理**。 只有分词后的 term，才能进入倒排索引；查询时的搜索词，也会使用相同分词器处理，保证 term 匹配。
#### 1、分词器三大组成部分

1. **Character Filter 字符过滤器**：预处理文本，比如替换 html 标签、特殊符号
2. **Tokenizer 分词器**：核心，按规则切词（标准分词、空格分词、ik 分词）
3. **Token Filter 词条过滤器**：对切出来的 term 加工，小写转换、去停用词、同义词、词干提取

#### 2、ES 内置分词器

- `standard`：标准分词器，英文按空格标点切，中文单字切（**中文业务绝对不要直接用**）
- `simple`：按非字母切分，全部小写
- `whitespace`：仅按空格切分，不做其他处理
- `stop`：标准分词 + 去除停用词（the、a、的、了）

#### 3、中文分词选型（生产最常用）

ES 原生不支持友好中文分词，主流插件：
1. IK 分词（ik_max_word /ik_smart）
	- `ik_max_word`：细粒度，拆分出尽可能多的词，适合检索
	- `ik_smart`：粗粒度，优先长词，适合标题
2. Jieba 分词：结巴分词
3. HanLP：语义效果更好，支持自定义词典、词性

>重点踩坑：**写入和查询必须使用同一个分词器**。如果建索引用 ik，搜索用 standard，term 对不上，搜不到数据。 自定义词典：热更新词典，不需要重启 ES，适合业务新增词（品牌、商品名）。

#### 4、精准匹配不分词场景

比如手机号、编号、枚举编码，不需要分词，字段类型设置为 `keyword`。 `keyword`：整个文本作为一个单独 term，适合精确检索、聚合、排序。 `text`：会分词，用于全文模糊搜索。
>常见 mapping 设计：一个字段同时存 text+keyword，`multi-fields`

```json
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "ik_max_word",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      }
    }
  }
}
```

### 四、ES 查询体系整理

ES 查询分为两大类：**查询上下文（query context）** 和 **过滤上下文（filter context）**，这个是所有查询的根基。
#### 1、Query vs Filter

- **query**：计算相关性`_score`，关心匹配程度，会走打分；不缓存
- **filter**：只判断是否匹配，不计算分数，结果可以缓存；性能更高，能命中缓存

>开发规范：能放到 filter 的条件，不要放到 query 里。比如状态、时间范围、分类 id 这类精确筛选条件，用 filter。

#### 2、常用 DSL 查询分类

#### （1）全文查询（text 字段，分词检索）

- `match`：最常用，搜索词先分词，再去匹配倒排索引；支持`operator:and/or`

```json
{
  "query": {
    "match": {
      "title": {
        "query": "后端开发",
        "operator": "and"
      }
    }
  }
}
```
- `match_phrase`：短语匹配，要求词条顺序连续、位置相邻，适合搜短句
- `multi_match`：多字段同时检索，比如标题 + 内容一起搜关键词

#### （2）Term 级别查询（keyword，不分词，精确匹配）

>term 查询**不会对搜索词分词**！很多新手踩坑：拿 term 去查 text 字段，搜不到结果。

- `term`：单值精确匹配
- `terms`：多值 in 查询
- `range`：范围（时间、数字）
- `exists`：字段是否存在
- `prefix`、`wildcard`、`regexp`：前缀、通配、正则，**性能差，尽量少用**，不走倒排索引优势

#### （3）复合查询

- `bool`：组合查询，业务开发 90% 场景都用 bool，包含 4 个子句
	- `must`：必须匹配，query 上下文，算分
	- `should`：可选匹配，满足加分；minimum_should_match 控制最少匹配数
	- `must_not`：必须不匹配，filter 上下文，不算分
	- `filter`：必须匹配，filter 上下文，不算分，可缓存

```json
{
  "query": {
    "bool": {
      "must": [{"match": {"title": "后端"}}],
      "filter": [
        {"term": {"status": 1}},
        {"range": {"create_time": {"gte": "2026-01-01"}}}
      ],
      "should": [{"match": {"author": "xxx"}}],
      "minimum_should_match": 0
    }
  }
}
```
- `constant_score`：把 filter 包起来，固定分数，适合不需要相关性打分的检索
- `dis_max`：多字段查询，取最高分，避免多个字段命中叠加分数过高

#### （4）聚合 Aggregation

ES 不只是搜，还擅长检索后统计分析，和 MySQL group by 类似，但分布式设计。
- Bucket 桶聚合：分组（terms、date_histogram 时间直方图、range）
- Metric 指标聚合：统计值（sum、avg、max、min、cardinality 基数去重）
- Pipeline 管道聚合：基于上一层聚合结果二次计算

>限制：深度分页 + 大聚合会有性能问题；`cardinality`是近似去重，不是精确 count distinct。

#### 3. 分页方案对比（面试高频）

1. `from + size`：浅分页，from 越大越慢；数据量大时禁止深分页（深度分页需要所有分片排序后汇总）
2. `scroll`：滚动分页，适合大批量导出数据，不适合实时翻页，有快照开销
3. `search_after`：推荐，基于排序值游标分页，无深度性能衰减，生产翻页首选

### 五、MySQL 和 Elasticsearch 的核心差异

很多后端开发都会混淆两者定位，一句话总结：**MySQL 主打事务、强一致、OLTP；ES 主打全文检索、海量数据聚合、OLAP 检索场景，不适合替代数据库**

|对比项|MySQL|Elasticsearch|
|:-:|:-:|:-:|
|核心定位|关系型事务数据库，业务主存储|搜索引擎，检索加速引擎，一般做从库同步|
|索引结构|B + 树，正排索引为主|Lucene 倒排索引，Segment 只读|
|事务|完整 ACID，支持事务、行锁|无分布式事务，单分片有原子性，不支持跨行事务|
|实时性|写入立即可查|近实时，默认 1s refresh 延迟|
|字段类型|强 Schema，表结构严格|动态 mapping，可自动推断类型，也可以手动严格 mapping|
|写入更新|原地更新|标记删除 + 新增文档，后台段合并清理|
|检索能力|等值、范围、前缀；模糊 like% xxx% 性能极差|全文分词检索、相关性打分、短语搜索、高亮、多维聚合|
|一致性|强一致（可配置隔离级别）|最终一致性；副本异步同步，读取可能读到旧数据|
|扩容|分库分表，业务侵入高|天然分布式，分片机制，横向扩容友好|
|适用场景|订单、用户、资金等核心业务主库|商品搜索、文章检索、日志检索、报表多维查询|
**标准业务架构**
MySQL 作为主库存储真实业务数据，通过 Canal / Binlog 同步数据到 ES，ES 只负责查询，写入和修改全部走 MySQL，ES 做数据副本。
>把 ES 当成主数据库存放订单、资金数据，一旦丢数据无法恢复，没有事务兜底。

### 六、Elasticsearch Master 选举机制

ES 集群的 Master 节点负责维护集群元数据：索引创建删除、分片分配、节点上下线感知。
>前提：只有配置了 `node.master: true` 的节点才有资格参与选举。生产一般设置 3 个 master 候选节点（奇数，防止脑裂）

#### 1、核心参数：discovery.zen.minimum_master_nodes（Zen 发现，ES7 之前）

ES7 之前使用 Zen Discovery，ES7 之后新集群发现机制叫**Zen2**，是默认方案。 Zen2 去掉了 `minimum_master_nodes`，引入**法定人数（Quorum）**：
>候选 master 节点数量为 N，Quorum = floor (N/2)+1 必须拿到 Quorum 票数，节点才能当选 master。 比如 3 个 master 候选：Quorum=2；必须至少拿到 2 票才能成为主节点。 为什么奇数？3 个节点，挂掉 1 个还剩 2，满足 Quorum；如果是 2 个候选，挂掉任意一个，剩下 1 个，Quorum=2 永远达不到，集群无主，不可写。

#### 2、Master 选举流程（Zen2）

1. 集群启动或者原 master 失联，所有 master 候选节点进入竞选状态
2. 每个候选节点先给自己投一票，然后向其他 master 候选节点发送投票请求
3. 节点收到投票请求，只会给**版本号最新的集群状态**节点投票（集群 state 版本号越大代表元数据越新）
4. 当某个候选节点收到票数 ≥ Quorum，成功当选 Master
5. Master 当选之后，发布最新集群状态给所有节点；其他节点不再发起竞选，进入跟随状态
6. Master 持续发送心跳，其他节点感知 master 存活；master 失联后，重新开启新一轮选举

#### 3、脑裂问题以及规避

脑裂：集群分裂成两个子集群，各自选出自己的 master，两份元数据各自修改，数据错乱。
- Zen2 通过 Quorum 机制天然降低脑裂概率：想选出 master 必须过半候选同意，网络分区下，不可能两边同时满足 Quorum
- 生产最佳实践：独立 3 台 master 节点，master 节点不承担 data 角色；保证 master 之间网络稳定，调大合理超时参数，避免网络抖动误判节点失联

#### 4、Master 职责边界

Master**不处理文档的读写请求**，只管理集群元数据；数据分片读写由 data 节点负责，协调节点负责请求路由转发。Master 负载很低，所以配置不需要很高磁盘，CPU 和内存稳定优先。

很多刚接触 ES 的同学会把索引直接类比成 MySQL 表，初期入门可以，但不能当成准确映射。本文从最小数据单元文档讲起，说明 _id、_source、_version 等元字段，以及文档“不可变更新”的本质：更新不是原地修改，而是标记旧文档删除并新增版本，后台段合并时才真正清理。接着梳理索引作为逻辑命名空间、ES7 后 Type 被彻底移除、分片是 ES 最小读写单元且主分片创建后不能修改、副本用于容灾和分担查询压力。最后介绍 master、data、ingest、coordinating 节点角色，并强调生产环境建议分离 master 与 data 节点。适合后端开发系统建立 ES 基础概念，避免把 ES 简单当表用。

Elasticsearch 入门别再把索引当表：文档、分片、副本一次讲清

从文档、索引、分片、副本到节点角色，梳理 ES 基础概念，并说明为什么索引不能简单等同于 MySQL 表，适合刚接触 ES 的后端开发入门。

Go开发工程师

编程语言

ES核心概念解析：从文档、索引、分片、副本到节点角色，再到倒排索引、分词器、Query/Filter查询及聚合分页。文章还对比MySQL与ES差异，分析Master选举机制与脑裂规避，为后端开发者构建完整ES知识体系，避免将ES简单类比为数据库表。

分布式存储

Elasticsearch 

数据分片

代码解释

数据库

路由

容灾

MySQL

OLTP

OLAP

JSON

让每一个 Agent，都跑在云上

日志服务CLS新用户首单0.8折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Elasticsearch 入门别再把索引当表：文档、分片、副本一次讲清-腾讯云开发者社区-腾讯云

Elasticsearch 入门别再把索引当表：文档、分片、副本一次讲清

Elasticsearch 入门别再把索引当表：文档、分片、副本一次讲清

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐