MongoDB-Spring Boot文档关联设计：两种方案性能与查询效率对比

问题背景 #

在Spring Boot中管理互相关联的MongoDB文档时，常见两种关联实现方案：

方案一：存储关联文档ID #

@Document
public class Customer {

   @MongoId
   private String id;
   private String addressId;
}

方案二：使用@DocumentReference注解实现关联 #

@Document
public class Address {
    @MongoId
    private String id;
    
    @DocumentReference(lazy = true, lookup = "{ 'primaryAddress' : ?#{#self._id} }")
    @ReadOnlyProperty
    private Customer customer;
}

@Document
public class Customer {

    @MongoId
    private String id;
    @DocumentReference(lazy = true)
    private Address primaryAddress;

}

以下从查询次数、性能效率、通用场景三个维度对比两种方案：

查询次数对比 #

• 方案一：默认仅查询主文档（如Customer），若需获取关联的Address数据，需手动通过addressId发起第二次查询。即：仅需主文档时1次查询，需关联数据时2次查询。
• 方案二：因配置了lazy = true，关联数据不会默认加载，仅当调用对应 getter 方法时，框架才自动触发额外查询。查询次数逻辑上与方案一一致：仅查主文档1次，访问关联数据时2次。若未开启懒加载（默认false），则会自动触发立即关联查询，查主文档时同步查关联文档，一次请求产生2次数据库查询。

性能效率对比 #

• 方案一：无框架额外封装开销，查询时机完全由开发者控制。但需手动处理关联数据的查询与映射，代码量略多。若业务场景中多数情况无需关联数据，该方案更高效，不会触发不必要的查询。
• 方案二：框架自动处理关联映射，代码更简洁，但会引入Spring Data MongoDB的封装层开销（如代理对象创建、动态查询解析），不过该开销在多数场景下可忽略。懒加载配置得当的话，性能与方案一持平；若误用立即加载，会导致无意义的关联查询，反而降低性能。

通用场景评估 #

方案一适用场景 #

• 关联数据访问频率低，多数场景仅需主文档数据
• 需要定制化关联查询逻辑（如关联时添加额外过滤条件）
• 对框架额外开销敏感的高性能场景

方案二适用场景 #

• 关联数据访问频率高，追求代码简洁、低维护成本
• 无需复杂关联逻辑，框架默认规则可满足需求
• 团队倾向于使用Spring Data标准化特性，减少重复代码

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