Elasticsearch 索引映射 Mapping 设计不当如何重新重建？

Elasticsearch 索引的映射（Mapping）一旦创建，大多数字段类型无法直接修改，最稳妥的处理方式是创建新索引并通过 Reindex API 迁移数据。

先说结论：映射设计错误无法原地修正，必须重建索引，建议通过别名机制平滑切换。

适合：字段类型错误、分词器配置需要变更、无法通过动态映射自动修正的场景
先准备：规划新映射结构、确认集群磁盘空间至少为原索引的 2 倍
验收：核对文档总数、抽样验证字段内容、原子切换别名

命令速用版

POST _reindex
{
  "source": {
    "index": "old_index",
    "size": 1000
  },
  "dest": {
    "index": "new_index"
  },
  "conflicts": "proceed",
  "max_docs": 10000
}

上述命令增加了冲突处理（conflicts）和分批控制（max_docs），实际生产中通常还需要配合新索引的 Mapping 定义和别名切换操作。

为什么会这样

Elasticsearch 底层使用 Lucene 存储数据，字段类型决定了数据在倒排索引中的存储结构。例如，text 类型会经过分词处理，而 keyword 类型则完整存储。一旦数据写入，存储格式就已固定，直接修改映射会导致查询错误或数据损坏。

官方文档明确指出，现有字段可以添加子字段或更新部分参数，但更改字段类型、分词器等核心配置必须重新索引数据。这是为了保证数据的一致性和查询的正确性，而非系统功能缺失。

分步处理

1. 导出并修正映射

先获取旧索引的映射结构，在本地修改错误的字段类型。注意不要直接在生产环境修改旧索引映射。

GET /old_index/_mapping

2. 创建新索引

使用修正后的映射创建新索引。如果旧索引有设置（Settings），如分片数、副本数，也需一并考虑，重建后分片数通常不可改，需提前规划。以下是将 text 类型字段修改为 keyword 的具体示例：

PUT /new_index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "user_name": {
        "type": "keyword"
      },
      "content": {
        "type": "text",
        "analyzer": "standard"
      }
    }
  }
}

3. 执行数据迁移

使用 Reindex API 将数据从旧索引复制到新索引。如果数据量大，建议设置 size 分批处理或调整 refresh 间隔以减少负载。生产环境建议添加冲突处理参数。

POST _reindex
{
  "source": {
    "index": "old_index",
    "size": 1000
  },
  "dest": {
    "index": "new_index"
  },
  "conflicts": "proceed",
  "max_docs": 100000
}

若需在迁移过程中转换数据格式，可在 source 中添加 script：

POST _reindex
{
  "source": {
    "index": "old_index",
    "script": {
      "source": "ctx._source.user_name = ctx._source.user_name.toLowerCase()",
      "lang": "painless"
    }
  },
  "dest": {
    "index": "new_index"
  }
}

4. 切换别名（Alias）

如果应用层通过别名访问索引，使用原子操作切换别名，确保业务无感知。如果没有别名，需协调业务停机窗口更改配置。

POST _aliases
{
  "actions": [
    { "remove": { "index": "old_index", "alias": "my_alias" } },
    { "add": { "index": "new_index", "alias": "my_alias" } }
  ]
}

5. 清理旧索引

观察新索引运行稳定后，再删除旧索引释放空间。不要急于删除，保留回滚余地。

怎么验证是否生效

1. 文档数量核对

对比新旧索引的文档计数，确保迁移过程中没有丢失数据。

GET /old_index/_count
GET /new_index/_count

2. 字段类型检查

查询新索引的映射，确认目标字段的类型已变更为预期值。

GET /new_index/_mapping/field/your_field_name

3. 业务查询验证

在应用层执行典型查询，确认搜索结果符合预期，特别是涉及排序、聚合的字段，类型错误会导致这些功能失效。

常见坑

1. 磁盘空间不足

重建索引期间，旧索引和新索引会同时存在，集群需要至少双倍于原索引大小的可用空间。如果空间不足，Reindex 会失败。

2. 别名切换非原子

务必使用 _aliases API 一次性完成 remove 和 add 操作。如果分两步执行，中间状态可能导致部分请求落到旧索引，部分落到新索引，造成数据不一致。

3. 脚本转换遗漏

如果迁移过程中需要修改数据内容（例如字段拆分、格式转换），需在 Reindex 的 source 中使用 script 处理。脚本逻辑错误可能导致数据脏写，需先在测试环境验证脚本。

4. 忽略设置（Settings）

重建索引时，Mapping 可以改，但 Settings 中的分片数（number_of_shards）创建后无法修改。如果原分片设计不合理，需借此机会重新规划，否则新索引很快又会面临扩展性问题。

5. 集群负载过高

基础 Reindex 命令未设置并发控制，大数据量下可能影响集群稳定性。建议通过 max_docs 分批执行，或在低峰期操作，必要时限制 reindex 请求的并发度。

参考来源

Elasticsearch 官方文档 - Reindex API: https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html
Elasticsearch 官方文档 - Mapping 参数说明：https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html