跨多个Solr文档实现同businessObjectId的AND匹配需求

嘿，这个问题我之前帮不少人解决过——本质是跨同组文档的条件匹配，当前的单文档查询逻辑满足不了，扁平化又丢了原数据的关联排序，我给你拆解几个可行的思路，重点说说你关心的嵌套对象方案：

你现在的困境是：Solr的默认查询是针对单个文档的字段匹配，clientNumber:565 AND productType:electronics要求这两个条件同时出现在同一个文档里，但你的数据是拆分到两个同businessObjectId的独立文档中的，所以自然匹配不到。而扁平化虽然能把同组字段合并成数组实现匹配，但会彻底丢失原文档的字段关联（比如你没法再对应contractNumber:421和clientNumber:565的绑定关系），排序逻辑也会完全混乱。

嵌套文档就是把同businessObjectId的多个子文档，挂载到一个父文档下，既保留子文档的独立结构，又能通过父-子关联实现跨子文档的条件查询。

第一步：重构文档结构 #

把你的数据改成嵌套格式：

[
  {
    "businessObjectId": 4,
    "_childDocuments_": [
      { "contractNumber": 421, "clientNumber": 565 },
      { "contractNumber": 455, "productType": "electronics" }
    ]
  },
  {
    "businessObjectId": 5,
    "_childDocuments_": [
      { "clientNumber": 222, "productType": "electronics" }
    ]
  }
]

这里父文档只保留businessObjectId作为分组标识，所有原文档的字段都放到子文档里，完美保留原有的字段关联和排序可能。

第二步：Schema配置要点 #

• 确保Solr支持嵌套文档：默认情况下Solr是支持的，不需要额外禁用，但如果你的Schema里有update.autoCreateFields=false，需要手动定义_childDocuments_字段为type="nested"（不过大部分场景下自动创建就能识别）。
• 子文档的字段保持原有配置：比如contractNumber设为int、indexed=true，clientNumber同理，不需要改成multiValued——子文档是独立的，每个子文档的字段都是单值，完全保留原数据结构。

第三步：编写查询语句 #

要匹配“同一businessObjectId下既有clientNumber:565的子文档，又有productType:electronics的子文档”，可以用Solr的父查询语法：

{!parent which="businessObjectId:*"}({!child of="businessObjectId:*"}clientNumber:565) AND {!parent which="businessObjectId:*"}({!child of="businessObjectId:*"}productType:electronics)

解释一下：

• {!parent which="businessObjectId:*"}指定我们要返回父文档（也就是businessObjectId对应的分组）
• 括号里的{!child of="businessObjectId:*"}是针对子文档的查询，分别匹配两个条件
• 整个逻辑就是：找到所有父文档，其下的子文档同时满足两个条件

如果需要返回子文档而不是父文档，也可以调整为子查询语法，灵活度很高，而且完全保留了原文档的排序能力（比如你可以按子文档的contractNumber排序，或者按父文档的businessObjectId排序后关联子文档）。

如果你不想重新组织嵌套结构，也可以用Join查询基于businessObjectId关联文档。查询语句如下：

businessObjectId:[* TO *] AND {!join from=businessObjectId to=businessObjectId}clientNumber:565 AND {!join from=businessObjectId to=businessObjectId}productType:electronics

这个逻辑是：先找到所有有clientNumber:565的文档，获取它们的businessObjectId，再找到这些businessObjectId下有productType:electronics的文档，最终返回符合条件的businessObjectId对应的文档。

不过这个方案的缺点是性能不如嵌套文档（尤其是数据量大的时候），而且返回的结果是单个子文档，需要自己再聚合到businessObjectId维度，排序逻辑也不如嵌套文档清晰。

你提到的扁平化会把同businessObjectId的字段合并成数组，比如：

{ "businessObjectId": 4, "contractNumber": [421, 455], "clientNumber": [565], "productType": ["electronics"] }

虽然能匹配到查询条件，但你丢失了字段间的关联关系——你没法知道contractNumber:421对应clientNumber:565，contractNumber:455对应productType:electronics。如果后续需要按contractNumber排序，或者筛选某个contractNumber对应的字段，扁平化后的数组完全无法支持这种精准关联的需求。

最推荐你用嵌套文档方案：既保留了原数据的完整结构和字段关联，又能实现跨子文档的条件匹配，同时支持灵活的排序和查询。只需要调整文档结构和少量Schema配置，就能完美解决你的问题。

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