Hibernate自引用多对多关系映射与查询实践指南

在Hibernate里处理自引用的多对多关系，比如药品分组里一个分组可以包含多个子分组，这种场景其实挺常见。但不少开发者会踩中一个“坑”：一不小心，就给同一张关联表配了两个方向相反的@JoinTable。结果就是，Hibernate在生成SQL时直接“懵了”，抛出一个让人摸不着头脑的语法错误，比如ERROR: syntax error at or near "."。问题的核心，往往出在QueryDSL这类工具试图去投影一个因为元数据冲突而未被Hibernate正确识别的集合属性路径上。

✅ 正确的实体映射方式

解决这个问题的关键，在于理清关系的“拥有方”。一个双向的多对多关系，必须且只能有一个方向来定义@JoinTable，这个方向就是拥有方；另一个方向则用mappedBy属性来引用拥有方的那个字段。如果两边都配了@JoinTable，Hibernate就会收到矛盾的指令，不知道该按哪个来生成关联表的操作逻辑，最终导致元数据解析失败和SQL构造错误。

@Entity
@Table(name = "medicaments_group")
@Getter
@Setter
public class MedicamentGroup extends GenericDictionary {
    @Id
    private Long id;
    @Column(name = "group_main")
    private boolean groupMain;
    @Column(name = "short_name")
    private String shortName;

    // 拥有方：负责维护关联表，定义 @JoinTable
    @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
    @JoinTable(
        name = "medicaments_group_join",
        joinColumns = @JoinColumn(name = "medicament_group_id"),      // 当前分组 ID
        inverseJoinColumns = @JoinColumn(name = "medicament_join_id") // 子分组 ID
    )
    private List childrens = new ArrayList<>();

    // 被拥有方：通过 mappedBy 关联到 childrens，不定义 @JoinTable
    @ManyToMany(mappedBy = "childrens")
    private List childrenOf = new ArrayList<>();
}

⚠️ 这里有几个关键点需要厘清：

• childrens字段是关系的拥有方。所有对关联表（medicaments_group_join）的插入和更新操作，都只由这个字段的映射配置来决定。
• childrenOf字段是纯粹的反向导航属性。它只用于数据读取，其内容会随着childrens集合的变动而自动同步。不过，为了确保双向关系在内存中的一致性，通常建议在业务方法里手动维护一下反向引用。
• 只有移除了重复的@JoinTable声明，QueryDSL或JPQL才能正确地将childrens识别为一个合法的关联路径进行查询。

✅ 安全获取分组及其子分组的推荐方式

映射配对了，查询也得跟上。在QueryDSL里直接select(..., childrens)很容易触发N+1查询问题，或者因为投影异常而失败。更稳妥的做法是使用JPQL的JOIN FETCH子句。它能确保在一次数据库查询中，就加载好主实体及其懒加载的集合，省心又高效。

@Repository
public class MedicamentGroupRepositoryImpl implements MedicamentGroupRepository {
    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public List getGroupsAndItsChildren() {
        String jpql = """
            SELECT DISTINCT mg FROM MedicamentGroup mg
            LEFT JOIN FETCH mg.childrens child
            WHERE mg.groupMain = false
            ORDER BY mg.id
            """;
        return entityManager.createQuery(jpql, MedicamentGroup.class)
                .getResultList();
    }
}

• LEFT JOIN FETCH：它的作用是强制初始化childrens这个懒加载集合，从而避免后续在Session关闭后访问时抛出LazyInitializationException。
• DISTINCT：因为JOIN操作可能导致根实体重复，DISTINCT关键字可以帮助去重。不过，Hibernate在将结果封装回实体列表时，通常也会自动处理掉重复的根对象。
• 这种方式直接返回完整的实体列表，比用QueryDSL的Tuple手动映射字段更简洁，也规避了字段投影出错的风险。

? 注意事项与最佳实践

把代码跑通只是第一步，要想用得稳，还得注意下面这些细节：

• 别靠“删库重跑”解决问题：有些临时性问题，比如缓存或元数据残留，可能通过重建数据库暂时绕过。但这绝不是解决方案，尤其在生产环境，这相当于掩耳盗铃，根本的映射逻辑缺陷依然存在。
• 级联操作要慎用：在@ManyToMany上使用CascadeType.ALL风险很高。想象一下，删除一个父分组，结果把所有子分组的关联记录甚至子分组本身都级联删除了，这很可能不是你想要的行为。通常，PERSIST和MERGE已经足够。
• 维护双向关系的一致性：Hibernate不会自动帮你维护内存中双向关系的两端。所以，最好提供一个业务方法来做这件事，例如：

  public void addChild(MedicamentGroup child) {
      this.childrens.add(child);
      child.childrenOf.add(this); // 维护反向引用
  }

• 关注性能，尤其是深层嵌套：如果分组关系可能形成非常深的树或无限递归，一次性JOIN FETCH加载整个树可能导致内存压力。这时需要考虑分页查询、使用@OrderBy控制加载顺序，或者在数据库层面利用CTE（公共表表达式）进行递归查询来优化。

按照上面的思路修正后，你就能稳定地获取到一个List，其中每个分组对象的childrens集合都已被预先加载好，无论是用于后端处理，还是直接提供给前端渲染树形组件，都会顺畅很多。