使用Flyway SQL脚本迁移表数据是否存在技术风险？

我的项目里有两张表：
【Legacy表】

【New表】（架构略有不同）

如你所见，Legacy表包含部分New表没有的数据——因为代码近期才开始向New表写入数据。我的任务是把Legacy表中id未在New表存在的数据迁移过去。

我的应用是基于Spring Boot Kotlin的简单API，使用Postgres数据库与Flyway工具。我想知道：额外编写Flyway SQL脚本处理该数据迁移是否会引发技术问题？我见过Flyway SQL脚本用于构建/修改架构，但未见过用于表间数据迁移，是否有理由不这么做？

答案：完全可以用Flyway做这类数据迁移，不存在本质技术问题 #

• Flyway原生支持数据迁移操作：Flyway的核心定位是管理数据库的所有版本化变更，不管是建表、改结构的DDL操作，还是插入、更新数据的DML操作，都在它的覆盖范围内。很多生产环境都会用它来处理数据迁移、批量数据修正这类场景，这是完全合理的用法。
• 需要注意几个关键细节：
  • 保证脚本幂等性：这是Flyway脚本的基本要求，避免重复执行时出错。比如你的迁移SQL可以这么写：

    INSERT INTO new_table (col_id, col_b, another_col)
    SELECT col_id, col_b, '默认值' -- 根据需求给another_col设置合适的默认值或从Legacy表的其他字段映射
    FROM legacy_table
    WHERE col_id NOT IN (SELECT col_id FROM new_table);
    

    这样即使脚本被重复执行，也不会插入重复数据。
  • 评估数据量影响：如果Legacy表数据量很大，一次性迁移可能会占用数据库资源、锁表，影响业务。这种情况可以考虑分批迁移，或者选择业务低峰期执行脚本。
  • 充分测试：先在测试环境完整跑一遍迁移脚本，验证数据准确性，同时检查迁移过程中对数据库性能、现有业务的影响。
• 关于“少见”的误解：很多团队会选择用应用代码处理数据迁移，但这只是不同的实现方式，不代表Flyway不适合。用Flyway的优势在于，迁移逻辑和数据库结构变更一起被版本化管理，追溯历史变更更清晰，也避免了应用代码中混杂大量数据迁移逻辑，保持代码整洁。

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