嘿，我完全懂你的困扰——不想删掉辛辛苦苦建的现有索引，但普通数组的扁平化存储又总是返回不符合预期的文档，对吧？其实除了重建索引加nested映射，还有几个可行的方案，我给你拆解下：

这个是最快速的临时方案，不用改任何映射，直接写脚本遍历数组，检查是否存在同时满足条件的元素。比如你要找数组里folder_id和is_rejected同时匹配的文档，可以这么写查询：

{
  "query": {
    "bool": {
      "filter": {
        "script": {
          "script": {
            "source": """
              for (def item : params._source.your_array_field) {
                if (item.folder_id == '目标folder_id' && item.is_rejected == false) {
                  return true;
                }
              }
              return false;
            """,
            "lang": "painless"
          }
        }
      }
    }
  }
}

优缺点：

• 优点：零配置，不用动索引，快速实现需求。
• 缺点：性能拉胯，因为脚本要遍历每个文档的数组，完全没法利用索引优化，只适合小数据集或者偶尔的查询。

这个是更适合生产环境的方案，不用删除现有索引，只需要添加一个join类型的字段，然后把数组元素拆成独立的子文档关联到父文档。步骤如下：

1. 先给现有索引添加join映射：

PUT /your_index_name/_mapping
{
  "properties": {
    "doc_join": {
      "type": "join",
      "relations": {
        "parent_doc": "array_item"
      }
    }
  }
}

2. 重新索引数据：把原来的主文档作为parent_doc类型，数组里的每个元素作为array_item类型的子文档，关联到对应的父文档。比如：
   父文档：

{
  "id": "original_doc_1",
  "other_parent_fields": "...",
  "doc_join": "parent_doc"
}

子文档（对应原数组的一个元素）：

{
  "id": "original_doc_1_item_1",
  "folder_id": "folder1",
  "is_rejected": false,
  "doc_join": {
    "name": "array_item",
    "parent": "original_doc_1"
  }
}

3. 用has_child查询来找到符合条件的父文档：

{
  "query": {
    "has_child": {
      "type": "array_item",
      "query": {
        "bool": {
          "must": [
            {"match": {"folder_id": "folder1"}},
            {"match": {"is_rejected": false}}
          ]
        }
      }
    }
  }
}

优缺点：

• 优点：能利用索引优化，性能好，支持复杂的关联查询，不用删除原索引。
• 缺点：需要重新组织数据结构，重新索引的工作量不小，而且查询语句会比nested复杂一点。

如果能接受暂时保留两个索引，也可以新建一个带nested映射的索引，把数据重新索引过去，验证没问题后再切换到新索引，最后删除旧索引。这种方式其实是官方推荐的最佳实践，虽然要重建索引，但不用停机，风险可控。

比如先创建新索引的映射：

PUT /new_index_name
{
  "mappings": {
    "properties": {
      "your_array_field": {
        "type": "nested",
        "properties": {
          "folder_id": {"type": "keyword"},
          "is_rejected": {"type": "boolean"}
        }
      }
    }
  }
}

然后用_reindex API把数据导过去：

POST _reindex
{
  "source": {"index": "old_index_name"},
  "dest": {"index": "new_index_name"}
}

这个方案的好处是后续查询可以用简洁的nested查询，性能也最优，只是需要一点迁移成本。

内容的提问来源于stack exchange，提问作者maral