何时/为何优先使用EntityManager.remove()而非JPQL删除查询？

我在培训课程中编写了两段删除Student对象的代码：

第一段代码（使用EntityManager.remove()） #

@Transactional
@Override
public void deleteStudent(Integer id) {
 
    //Using entityManager.remove causes two queries, I dunno why/when this is used!
 
    Student student = entityManager.find(Student.class, id);
 
    System.out.println("Deleting student with id "+student);
 
    entityManager.remove(student);
 
}

这段代码会触发两条SQL查询：

Hibernate: select s1_0.id,s1_0.email,s1_0.first_name,s1_0.last_name from student s1_0 where s1_0.id=?
Deleting student with id Student{id='5', firstName='Paul', lastName='Dove', email='pault.dove@somemail.com'}
Hibernate: delete from student where id=?

第二段代码（使用JPQL显式删除查询） #

@Transactional
@Override
public void deleteStudentEfficient(Integer id) {
 
    int noOfRowsDeleted = entityManager.createQuery("delete from Student where id = :id").setParameter("id", id).executeUpdate();
 
    System.out.println("Deleting student with id: "+id+" noOfRowsDeleted: "+noOfRowsDeleted);
 
}

仅会触发一条SQL查询：

Hibernate: delete from student where id=?
Deleting student with id: 3 noOfRowsDeleted: 1

疑问： #

何时/为何要优先使用EntityManager.remove()而非entityManager.createQuery(...).setParameter("id", id).executeUpdate()？我忽略了哪些要点？

优先使用EntityManager.remove()的场景与原因： #

• 需要触发实体生命周期回调
  如果Student类定义了@PreRemove、@PostRemove这类生命周期注解，只有调用remove()时才会触发这些回调逻辑。JPQL批量删除是直接操作数据库，不会加载实体到持久化上下文，自然不会触发任何实体生命周期事件。

• 保证持久化上下文的一致性
  remove()会先把实体加载到持久化上下文，删除后上下文内的实体状态会同步更新为已删除状态。如果当前事务中还有其他操作依赖该实体的状态，用JPQL删除的话，持久化上下文里可能还留存旧的实体对象，会导致后续操作出现数据不一致的问题。

• 自动处理级联删除
  若Student与其他实体（比如Course）配置了cascade=CascadeType.REMOVE或cascade=CascadeType.ALL的关联关系，调用remove()会自动触发关联实体的级联删除。JPQL删除不会处理级联逻辑，必须手动编写额外的JPQL语句删除关联数据，否则会触发数据库外键约束报错。

• 业务逻辑依赖实体数据
  如果删除前需要读取实体属性做业务判断（比如检查学生是否有未完成的课程、删除时需要记录学生的姓名邮箱到日志），remove()先加载实体的方式更直接，无需额外编写查询语句获取这些数据。

你忽略的核心要点： #

JPQL批量删除是直接对数据库执行DML操作，绕过了JPA的持久化上下文与实体生命周期管理，优势是性能更高（少一次查询），但代价是失去了JPA提供的封装特性。而EntityManager.remove()遵循JPA实体管理规范，保证了数据与上下文的一致性，能触发相关回调与级联操作，适合需要完整实体生命周期管理的业务场景。

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