Spring Boot JPA deleteByCollectionId删除时行计数异常报错排查

这个报错是Hibernate批量操作的行数校验机制和Spring Data JPA派生删除方法的默认执行逻辑冲突导致的，偶发的触发场景通常和数据一致性、执行逻辑有关：

1. 你当前使用的无自定义SQL的deleteByCollectionId派生方法，默认执行逻辑不是直接发送单条批量DELETE语句，而是分为两步：先查询出所有匹配collectionId的实体存入持久化上下文（一级缓存），再逐个调用remove()方法生成单条删除SQL，攒成批次提交到数据库。
2. Hibernate提交批量删除时，会默认校验每条单条DELETE语句的影响行数为1，一旦出现以下任意情况，就会抛出你看到的BatchedTooManyRowsAffectedException：
   • 同一个事务内，在执行该删除方法前已经手动/通过其他逻辑删除了部分匹配的实体，持久化上下文的脏数据没有及时刷新，导致实际提交删除时部分实体已经不存在
   • 数据库层面给myCollection表配置了DELETE触发器，或者关联外键配置了级联删除规则，单条DELETE语句执行时额外影响了其他行数据，导致JDBC返回的影响行数大于1
   • 存在并发操作：多个事务同时删除同一个collectionId下的数据，当前事务查询到实体列表后，部分数据已经被其他事务提前删除/修改，提交删除时实际影响行数和预期不匹配
     你在备注里提到collectionId允许对应多条数据，本身就不符合派生删除方法默认逐行删除的预期场景，长期运行出现偶发报错是必然的。

按优先级推荐以下方案：

• 优先使用显式批量删除：直接通过@Query注解定义删除语句，让框架直接执行单条批量DELETE SQL，跳过逐实体查询、删除、行数校验的流程，性能更高也不会触发该报错：

@Transactional
@Modifying(clearAutomatically = true, flushAutomatically = true)
@Query("DELETE FROM Collection c WHERE c.collectionId = :collectionId")
void deleteByCollectionId(Long collectionId);

注意加上clearAutomatically和flushAutomatically属性，避免删除后持久化上下文残留的旧实体数据导致后续查询出错。

• 如果必须保留逐实体删除逻辑（比如需要触发@PreRemove等实体生命周期回调、需要走JPA配置的级联删除规则）：
  • 检查数据库是否存在针对该表的DELETE触发器、外键级联规则，确认单条删除语句的影响行数确实为1
  • 给删除方法加上事务隔离级别配置，或者在删除前主动调用flush()清空持久化上下文的脏数据，避免缓存和数据库实际数据不一致
  • 对collectionId相关的删除操作加分布式锁/数据库悲观锁，避免并发删除导致的行数不匹配问题

你当前实体类使用的ID生成策略是Hibernate内置的increment，该策略在单实例部署下可以正常运行，但如果是多实例集群部署，会因为每个实例单独维护内存自增序列出现主键重复问题，建议替换为IDENTITY（数据库自增）、SEQUENCE或者分布式ID生成方案。

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