如何在JPA中正确删除父实体的ManyToOne关联关系？

问题场景 #

现有两个JPA实体：User和Badge，为多对一关联（多个Badge属于一个User），代码如下：

User实体 #

@Entity
@Table(name = "user")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    
    private String name;
    
    private String lastname;
    
}

Badge实体 #

@Entity
@Table(name = "badge")
public class Badge {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    
    private String code;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "badge_id")
    private User user;
    
}

对应的服务层代码：

BadgeService #

@Service
public class BadgeService {

    @Autowired
    BadgeRepository badgeRepository;
    
    public void delete(int id) {
        badgeRepository.deleteById(id);
    }
    
}

UserService #

@Service
public class UserService {

    @Autowired
    UserRepository userRepository;
    
    public void delete(int id) {
        userRepository.deleteById(id);
    }
    
}

删除徽章时操作正常，但删除用户时会触发外键约束报错。我想到两种解决方法，但不确定哪种更合适，或者是否存在更优方案：

方案一：手动删除关联徽章 #

在BadgeRepository中新增批量删除方法：

public interface BadgeRepository extends CrudRepository<Badge, Integer> {

    @Modifying
    @Query(value = "DELETE Badge b WHERE b.user.id = :userId")
    public void deleteByUserId(@Param("userId") int userId);

}

在BadgeService中添加对应的业务方法：

@Service
public class BadgeService {

    @Autowired
    BadgeRepository badgeRepository;

    public void delete(int id) {
        badgeRepository.deleteById(id);
    }

    @Transactional
    public void deleteByUserId(int userId) {
        badgeRepository.deleteByUserId(userId);
    }

}

修改UserService，删除用户前先删除其关联的所有徽章：

@Service
public class UserService {

    @Autowired
    UserRepository userRepository;
    
    @Autowired
    BadgeService badgeService;
    
    @Transactional
    public void delete(int id) {
        badgeService.deleteByUserId(id);
        userRepository.deleteById(id);
    }
    
}

缺点 #

如果User存在多个关联实体，UserService需要注入大量其他服务，导致代码耦合度升高。

方案二：改为双向关联并使用级联删除 #

修改User实体，添加双向关联并配置级联删除：

@Entity
@Table(name = "user")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;

    private String name;

    private String lastname;

    @OneToMany(mappedBy = "user", cascade = CascadeType.REMOVE, orphanRemoval = true)
    private List<Badge> badges = new ArrayList<Badge>();

}

删除用户时，JPA会自动级联删除所有关联的Badge。

缺点 #

• 会产生额外的查询语句，需要先加载用户的所有关联徽章
• 如果关联的徽章数量过大，会显著降低应用性能

推荐方案与更优实践 #

优先推荐：方案一的解耦优化版 #

方案一的核心问题是耦合度，我们可以通过领域事件来实现解耦：

1. 定义一个UserDeletedEvent事件，当用户删除时发布该事件
2. BadgeService监听这个事件，在事件回调中执行关联徽章的删除操作
3. 后续新增其他关联实体时，只需新增对应的事件监听器即可，无需修改UserService

示例代码（基于Spring事件）：

定义事件类

public class UserDeletedEvent {
    private final Integer userId;

    public UserDeletedEvent(Integer userId) {
        this.userId = userId;
    }

    public Integer getUserId() {
        return userId;
    }
}

修改UserService发布事件

@Service
public class UserService {

    @Autowired
    UserRepository userRepository;
    
    @Autowired
    ApplicationEventPublisher eventPublisher;
    
    @Transactional
    public void delete(int id) {
        userRepository.deleteById(id);
        eventPublisher.publishEvent(new UserDeletedEvent(id));
    }
    
}

BadgeService监听事件

@Service
public class BadgeService {

    @Autowired
    BadgeRepository badgeRepository;

    public void delete(int id) {
        badgeRepository.deleteById(id);
    }

    @Transactional
    @EventListener
    public void handleUserDeleted(UserDeletedEvent event) {
        badgeRepository.deleteByUserId(event.getUserId());
    }

}

这种方式既保留了方案一的高效（批量SQL删除，无需加载大量实体），又解决了耦合问题，扩展性更好。

数据库层面的终极优化 #

如果业务上允许，还可以直接在数据库的外键约束上配置ON DELETE CASCADE，让数据库自动处理关联数据的删除：

1. 修改Badge实体的@JoinColumn注解，添加外键约束的级联规则：

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "badge_id", foreignKey = @ForeignKey(foreignKeyDefinition = "FOREIGN KEY (badge_id) REFERENCES user(id) ON DELETE CASCADE"))
private User user;

或者直接在数据库中修改外键约束，添加ON DELETE CASCADE。

这种方式的优势：

• 完全无需在业务代码中处理关联删除，代码最简洁
• 数据库层面的级联操作性能最高，避免了应用层的多次查询或批量操作
• 不会产生额外的实体加载开销

注意事项：

• 需要确保数据库支持该特性（主流数据库如MySQL、PostgreSQL都支持）
• 要谨慎使用，避免因误删导致的数据丢失，建议配合事务使用

方案二的适用场景 #

方案二仅适用于关联集合较小的场景，比如用户关联的徽章数量很少，此时加载集合的性能开销可以忽略。如果集合规模不可控，不推荐使用。

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