Spring JPA+Hibernate事务中先删后创实体触发唯一键约束违规

你的核心问题出在持久化上下文状态不一致，以及删除操作的执行时机逻辑错误：

• 你先调用bRepository.delete(b)，但此时A的bSet还持有这些待删除的B引用，Hibernate的持久化上下文会认为这些实体仍被关联，导致删除语句可能被延迟执行，甚至调用flush也无法强制触发真正的数据库删除。
• 循环里逐个flush不仅效率极低，还可能因为上下文状态未同步，导致删除操作根本没落地到数据库，新B插入时自然触发唯一键冲突。

修正方案 #

按「解除关联 → 批量删除 → 强制flush → 创建新实体」的顺序调整逻辑：

@Transactional
void removeOldBsAndCreateNewOnes(A a) {
    // 1. 筛选出需要删除的B
    Set<B> removedBs = a.getBs().stream()
            .filter(/* 你的筛选逻辑 */)
            .collect(Collectors.toSet());

    // 2. 先从A的关联集合中移除待删除的B，解除持久化上下文的关联绑定
    a.getBs().removeAll(removedBs);

    // 3. 批量删除旧B，再强制flush确保删除语句执行到数据库
    bRepository.deleteAll(removedBs);
    bRepository.flush();

    // 4. 创建新B并保存，添加到A的集合中
    Set<B> newBs = new HashSet<>();
    // 生成新B的业务逻辑
    bRepository.saveAll(newBs);
    a.getBs().addAll(newBs);
}

关键细节说明 #

• 先解除关联再删除：必须先从A的bSet里移除待删除的B，否则Hibernate会因为关联关系的存在，无法正确标记这些B为待删除状态，flush也不会生成对应的DELETE语句。
• 批量操作替代循环逐个处理：deleteAll比循环里的delete更高效，还能让Hibernate一次性处理所有删除请求，flush时确保所有DELETE语句都执行完毕。
• flush时机：删除操作后立即flush，确保数据库里的旧B已经被清除，此时插入新B就不会触发唯一键约束了。

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