开启hibernate.order_inserts=true批量插入时外键冲突问题排查

首先直接回应你的疑问：这大概率是Hibernate在特定场景下的bug残留，而非你的配置错误——虽然HHH-9864声称修复了插入顺序问题，但5.2.17.Final版本的修复可能没有覆盖到你这种双向OneToOne+级联保存的场景。

问题根源解析 #

当你开启hibernate.order_inserts=true时，Hibernate会对所有待执行的插入语句按表分组排序，以此优化批处理的性能。但在你的双向OneToOne关联中：

• PlanItemDefinition持有指向PlanItemControl的外键default_control_id
• 两者互为关联，且配置了CascadeType.ALL级联保存

Hibernate的插入排序逻辑可能没有正确识别这种循环依赖的级联关系，错误地优先插入了PlanItemDefinition，而此时关联的PlanItemControl尚未被插入，导致外键约束校验失败。

HHH-9864的修复主要针对单向关联或更简单的级联场景，但双向OneToOne的依赖关系更复杂，5.2.17.Final版本的排序器可能没处理好这种优先级判断。

可行的解决/验证方案 #

• 临时调整保存顺序（应急方案）：
  虽然你用了级联保存，但可以在事务中手动先保存PlanItemControl实例，再将其关联到PlanItemDefinition后保存主实体。手动干预顺序可以绕过Hibernate的自动排序逻辑，避免外键冲突。
• 升级Hibernate版本：
  5.2.x系列属于较旧的稳定版，后续的5.2.22.Final（同系列最新）或5.3+/5.4+版本可能进一步修复了该场景的问题。建议尝试升级到更高版本验证是否解决。
• 针对性调整映射配置：
  可以尝试修改PlanItemDefinition中的@OneToOne注解，添加optional = false（如果该外键确实非空），这可能帮助Hibernate更准确地识别依赖关系；或者考虑调整外键的维护方（不过这会改变数据库结构，需谨慎评估）。
• 提交新的Issue（若升级后仍存在）：
  如果你升级到最新稳定版后问题依旧，建议到Hibernate的官方Issue Tracker提交复现案例，说明这是HHH-9864未覆盖的场景，帮助官方修复。

关于自身配置的排查 #

虽然可能性较低，但可以快速排查：

• 检查是否存在自定义的Hibernate拦截器、事件监听器，是否修改了默认的插入执行顺序
• 确认uuid2生成器的配置是否正确，是否存在ID生成的时序问题（不过从错误信息看ID是正常生成的，只是插入顺序错了）

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