同时使用Hibernate与Flyway时，是否需保留重复的索引约束配置？

核心原则 #

明确分工：Flyway负责数据库结构的版本化管理与初始化，Hibernate专注于实体与数据库的映射，避免职责重叠导致的冗余和冲突。

两种主流使用模式 #

模式一：Flyway主导数据库结构（推荐生产环境） #

• 所有表、索引、约束、唯一键的创建/修改都通过Flyway的SQL迁移脚本完成，彻底禁用Hibernate的自动DDL功能。
• 配置Hibernate的spring.jpa.hibernate.ddl-auto为none，切断Hibernate修改数据库结构的权限。
• 优势：数据库结构完全可控，迁移脚本可追溯、可回滚，团队协作时不会因为实体注解变更导致意外的数据库修改。
• 示例：
  Flyway迁移脚本V1__create_user_table.sql：

  CREATE TABLE user (
      id BIGINT PRIMARY KEY AUTO_INCREMENT,
      email VARCHAR(255) NOT NULL UNIQUE,
      username VARCHAR(50) NOT NULL,
      INDEX idx_username (username)
  );
  

  Hibernate实体类仅保留映射注解：

  @Entity
  @Table(name = "user")
  public class User {
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      private Long id;
      
      @Column(name = "email", nullable = false)
      private String email;
      
      @Column(name = "username", nullable = false)
      private String username;
      
      // getter/setter
  }
  

模式二：Hibernate生成基础结构，Flyway负责补充（适合快速原型/开发阶段） #

• 开发阶段开启Hibernate的ddl-auto为create或update，让Hibernate自动生成基础表结构，减少手动写SQL的工作量。
• Flyway负责处理Hibernate难以实现的复杂结构（比如分区表、自定义存储过程），以及填充初始化数据（比如字典表数据）。
• 注意：进入测试/生产环境前，必须将Hibernate生成的结构导出为Flyway的初始迁移脚本，然后禁用ddl-auto，切换为Flyway主导模式，避免环境结构不一致。

为什么会出现两处重复配置？ #

• 历史遗留：项目初期用Hibernate自动DDL，后期引入Flyway时未清理实体上的结构注解。
• 认知误区：误以为实体注解能完全同步数据库结构，忽略了Flyway版本化管理的必要性。
• 临时方案：开发阶段为快速验证同时保留两种配置，但未及时清理。

最佳实践建议 #

• 生产环境强制使用Flyway主导模式，所有结构变更必须通过迁移脚本提交，经代码评审后执行。
• 开发阶段可用Hibernate的create-drop快速迭代，但要定期将生成的结构同步到Flyway脚本。
• 实体类仅保留映射相关注解（@Entity、@Id、@Column等），将结构类注解（@Index、@UniqueConstraint等）全部迁移到Flyway脚本。
• 禁止在Flyway脚本中重复创建Hibernate已生成的结构，避免执行冲突。

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