AWS Aurora MySQL 5.6 v1.22.2搭配EclipseLink JPA出现父子表数据自动丢失问题

依赖变更触发异常的可能性 #

pom.xml的通用依赖变更完全可以触发该类异常，尤其是涉及JPA实现、JDBC驱动、数据库连接池三类组件的版本变动、间接依赖引入，都是该类问题的高频诱因。此前业务已稳定运行7年，说明原有业务逻辑、JPA配置本身不存在原生逻辑错误，问题大概率是依赖变更后，原有配置的执行逻辑出现了预期外的变动。

核心排查方向 #

1. 注解执行逻辑变动排查 #

你当前使用的Eclipselink专属注解@CascadeOnDelete，设计初衷是生成DDL时为外键自动添加ON DELETE CASCADE属性，但部分版本的Eclipselink会在运行期额外触发级联删除逻辑，尤其是实体关系解析异常时会出现全表删除的问题：

注意你提供的@OneToMany配置存在两处需要核对的点：一是代码中写的MappedBy首字母大写，JPA规范要求该属性为小写mappedBy；二是注解未写闭合括号。如果依赖变更后Eclipselink的注解校验逻辑变松，错误的配置会导致父子表关系解析异常，触发全量级联删除。

2. 依赖变更内容核对 #

• 优先核对是否调整过Eclipselink版本、MySQL JDBC驱动版本、Aurora专属连接适配包版本：Eclipselink 2.7.4存在已知的级联删除逻辑BUG，当持久化上下文加载了全量transactions实体后，只要对任意一个transactions实体执行删除操作，会错误触发全量关联实体的级联删除。
• 核对是否引入了新的JPA相关依赖（比如Spring Data JPA版本升级、JPA API包版本冲突）：不同版本的JPA实现对级联规则的解析逻辑存在差异，依赖冲突会导致实际生效的级联规则和配置的不一致。

3. 临时规避方案 #

• 先移除@CascadeOnDelete注解，手动在数据库层面维护外键关联逻辑，避免JPA层自动触发非预期的级联删除。
• 开启数据库的全量SQL审计日志，定位删除操作触发时执行的具体SQL语句，即可快速定位是业务逻辑问题还是JPA实现自动生成的错误SQL。

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