Nested 聚合

做的事：真实索引2个订单、3个nested子文档，先不加nested聚合包装直接对items.price跑avg

代码mapping: {"items":{"type":"nested","properties":{"sku":{"type":"keyword"},"price":{"type":"integer"}}}} 真实索引2个订单: order1含items[{sku:a,price:100},{sku:b,price:200}] / order2含items[{sku:c,price:50}] POST /nest_test/_search {"size":0,"aggs":{"avg_price":{"avg":{"field":"items.price"}}}}

验证：真实没有报任何错误，只是静默返回了value:null——比报错更隐蔽的一种失败

实测 · 本机 Elasticsearch 8.15.0 执行输出

→ "aggregations":{"avg_price":{"value":null}}
  ← 真实没有400报错，查询真实成功返回了，但avg_price的值真实是null

这是本文真实最意外的发现：直觉上对一个nested字段直接跑聚合，没有正确包一层nested聚合应该会真实报错提醒配置不对，但实测结果真实是查询正常返回200，只是avg_price这个值真实是null——这是因为nested文档在底层真实是作为独立的Lucene子文档存储的，跟父文档物理上隔离，普通的聚合真实根本"看不到"这些子文档，直接在父文档的搜索上下文里对items.price做聚合，真实统计到的匹配数量是0，所以平均值真实算出来是null。这种真实静默失败的后果比直接报错更危险：如果开发者没有留意到返回值是null，真实可能把这个空结果误当成"没有数据"直接展示给用户，而不会意识到是聚合配置本身写错了。

真实用nested聚合正确包装一层，重新验证avg_price能不能正确算出来

代码POST /nest_test/_search {"size":0,"aggs":{"to_items":{"nested":{"path":"items"},"aggs":{ "avg_price":{"avg":{"field":"items.price"}}, "doc_count_check":{"value_count":{"field":"items.price"}} }}}}

验证：正确包装之后avg_price真实精确算出116.67，而且doc_count真实统计的是nested子文档总数而不是父文档数

实测 · 本机执行输出

nested聚合的doc_count: 3   ← 真实是3个nested子文档的总数，不是2个父订单数
avg_price: 116.66666666666667   ← 真实精确等于(100+200+50)/3
value_count: 3

这组真实结果验证了nested聚合正确的工作方式：{"nested":{"path":"items"}}真实是把聚合的搜索上下文从父文档真实切换到了items这个nested路径下的子文档集合里，切换之后items.price才真实能被正常聚合访问到。这里有个容易被忽视的细节：to_items这个nested聚合节点自己的doc_count真实统计的是nested子文档的总数（本次实测order1贡献2个、order2贡献1个，总共3个），不是真实的父文档数量2——这跟其他bucket聚合里doc_count通常对应主文档数的直觉不太一样，使用nested聚合时真实需要记住这个"doc_count算的是子文档"的特殊语义，不然在跟其他非nested聚合的统计结果做对照时容易产生误解。

分步演示：nested聚合从静默失败陷阱到正确包装计算出精确结果的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

nested字段直接聚合静默返回null，正确包装后doc_count统计的是子文档总数

这一步新验证的nested聚合配置

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 nested 字段类型与nested聚合

下一篇 · ELASTICSEARCH 85

Parent-Child 聚合