Flyway能否检测外部非预期的数据库变更？

嘿，我来帮你理清Flyway在这里的工作逻辑——你遇到的情况其实是Flyway默认行为的正常表现，不过确实有办法检测到这类绕过它的变更，下面给你详细拆解：

为什么validate和info默认识别不了外部变更？ #

首先得明确这两个命令的核心作用：

• flyway validate：它只会校验Flyway已执行过的迁移脚本的本地版本和flyway_schema_history表中记录的校验和是否一致，防止有人篡改了已经运行过的迁移脚本。它完全不会关注数据库中有没有额外的、Flyway没记录的变更（比如手动新增的表、修改的列）。
• flyway info：只是列出所有迁移脚本的状态（已执行、待执行、跳过等），同样不会主动扫描数据库的实际结构和迁移脚本预期结构的差异。

检测外部变更的可行方案 #

方案1：Flyway Community版（免费版）的替代方法 #

因为Community版没有原生的Schema对比功能，你可以通过以下方式实现检测：

• 定期导出Schema并对比：编写脚本定期导出生产数据库的Schema结构（比如用pg_dump -s针对PostgreSQL，mysqldump -d针对MySQL），同时基于本地所有迁移脚本创建一个临时测试库，执行完所有迁移后导出它的Schema，再用Schema对比工具（比如开源的SchemaSpy、或者简单的文本对比工具）找出两者的差异，这些差异就是外部产生的变更。
• 自定义校验脚本：你可以编写SQL脚本，查询flyway_schema_history表获取已执行的迁移，然后对比数据库中实际存在的对象（表、视图、约束等）和迁移脚本中定义的对象是否一致，比如检查是否有额外的表存在。

方案2：Flyway Teams版（付费版）的原生功能 #

如果你能使用付费的Teams版，那就简单多了：它内置了Schema Comparison功能，直接运行flyway diff命令，就能自动对比数据库的实际状态和所有迁移脚本执行后的预期状态，清晰标出所有非Flyway产生的变更，比如新增的表、修改的列、删除的约束等，还能生成修复这些差异的迁移脚本。

总结 #

Flyway Community版需要借助外部工具或自定义脚本来检测绕过Flyway的数据库变更，而Teams版则提供了原生的、开箱即用的Schema对比能力来解决这个问题。

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