可重复数据库迁移是否存在合理的应用场景？

你提到的担忧完全合理——可重复迁移确实容易被滥用，甚至违背数据库迁移「确保状态可追溯、一致」的核心逻辑，但它并非毫无价值，在特定场景下能解决版本化迁移无法高效处理的问题：

一、合理的应用场景 #

1. 频繁迭代的只读计算对象（视图、函数、存储过程） #

对于不修改底层表结构、仅基于现有表做数据计算的对象，比如报表视图、统计函数、只读存储过程，这类需求往往会频繁调整（比如运营每周要修改报表维度）。如果每次变更都新增版本化迁移文件，会导致迁移脚本数量爆炸，且这类对象的价值在于「适配当前最新的表结构」，而非保留历史版本。

只要确保Flyway按「先执行所有版本化迁移，再执行可重复迁移」的默认逻辑运行，就不会出现你说的「表结构更新后存储过程失效」的问题——版本化迁移先完成表结构变更，可重复迁移再同步更新依赖的计算对象，保证状态一致。

2. 环境特异性的参考/测试数据初始化 #

不同环境（开发、测试、预发）往往需要不同的参考数据：比如开发环境需要批量模拟用户，测试环境需要符合特定用例的测试数据。这些数据不需要和业务版本绑定，而是需要随环境需求随时调整。用可重复迁移可以在每次部署时自动同步最新的环境数据，避免手动维护多份分散的脚本。

3. 动态生成的数据库对象 #

如果某些数据库对象是通过模板或配置动态生成的（比如根据业务配置生成分区函数、根据枚举值生成 lookup 视图），这类脚本的内容会随模板/配置变化而更新。用可重复迁移可以自动检测脚本内容的变更并重新执行，无需每次手动生成版本化迁移文件，减少重复工作。

二、必须遵守的使用边界 #

为了避免你提到的状态不一致问题，使用可重复迁移必须严格遵守以下规则：

• 绝对禁止用于核心表结构变更：所有涉及表创建、字段增删改、约束调整的操作，必须用版本化迁移，确保状态可追溯。
• 执行顺序不可修改：必须保留Flyway默认的「版本化迁移优先，可重复迁移在后」的执行顺序，避免依赖对象提前执行导致失效。
• 依赖检查不可少：对于依赖表结构的计算对象，可重复迁移脚本中要增加前置检查（比如判断表字段是否存在），确保执行时底层结构已就绪。
• 仅用于非核心数据：可重复迁移只能处理参考数据、测试数据，绝对不能用于业务数据的修改或插入，避免数据丢失或不一致。

总结 #

可重复迁移是版本化迁移的补充工具，而非替代品。它的核心价值在于处理「不需要追溯历史版本、只需适配当前数据库最新状态」的场景。很多团队滥用它，本质是没搞清楚两者的边界，把本该用版本化迁移的核心结构变更放到了可重复迁移中，才导致了状态混乱的问题。

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