查 flyway_schema_history 表是最直接的方式：Flyway 执行迁移后自建该表记录脚本、状态等，Navicat 中需确认 schema 位置并检查 installed_rank、script、state（须为 success）、installed_on；state 为 pending/failed/repair_required 表示异常；还需结合业务表结构与数据验证，并注意字符集及约束冲突问题。
查 flyway_schema_history 表是最直接的方式
flyway 执行完迁移后，会在目标数据库里自动建一张 flyway_schema_history 表（默认名，可配），记录每次执行的脚本、状态、校验和等。navicat 连上库后，直接展开表列表找到它，双击打开——这是验证是否成功最权威的依据。
重点看这几列：installed_rank（执行顺序）、script（文件名，如 V1.0__init.sql）、state（必须是 success）、installed_on（时间戳是否合理）。如果某条记录 state = 'pending' 或 'failed'，说明那条迁移根本没跑通。
- 注意：Flyway 6+ 默认启用 checksum 验证，改过已执行的 SQL 文件会导致
state = 'repair_required'，不能靠重跑解决，得手动flyway repair或删记录（不推荐） - 如果 Navicat 显示表不存在，先确认是否用了非默认 schema —— Flyway 可能建在
public以外的地方，比如schema: my_app，这时要在 Navicat 左侧连接树里切到对应 schema 下找
对比迁移前后的表结构或数据变化
光看 flyway_schema_history 只能证明“Flyway 认为自己跑完了”，不能代替业务验证。比如一个 V2.0__add_user_status.sql 应该加字段，就得在 Navicat 里右键对应表 → “设计表”，确认 status 字段真出现了；如果是插入初始数据的脚本，就直接查表看行数或内容。
- Navicat 的“查询”窗口支持多标签，建议开两个：一个查
flyway_schema_history，一个查业务表，方便来回比对 - 注意字符集/排序规则影响：某些迁移脚本里写了
COLLATE utf8mb4_0900_as_cs，但 Navicat 默认连接参数可能没设对，导致查出来字段显示为空或乱码，这时要右键连接 → “编辑连接” → “高级” → 勾选“初始化时设置字符集”，填utf8mb4
遇到 ERROR: duplicate key value violates unique constraint 怎么快速定位
这错误常出现在重复执行同一版本迁移（比如本地误点两次），或 flyway_schema_history 被手动删了但表结构已存在。在 Navicat 里别急着重启 Flyway，先做三件事：
- 查
SELECT * FROM flyway_schema_history WHERE script = 'V1.2__xxx.sql';—— 看是否已有记录且state = 'success' - 查对应业务表是否存在同名约束：
SELECT conname FROM pg_constraint WHERE conrelid = 'your_table'::regclass;（PostgreSQL）；MySQL 则查information_schema.KEY_COLUMN_USAGE - 如果确认脚本确实不该再执行，但 Flyway 还要硬跑，说明
flyway_schema_history里缺记录或 rank 错乱，此时需人工补一条state = 'ignored'记录（仅限开发环境）
Navicat 自带的“同步结构”功能别乱用
有人想用 Navicat 的“数据库同步”功能反向生成 DDL 来验证迁移结果，这很危险。因为 Flyway 迁移可能包含逻辑处理（如 UPDATE ... SET status = CASE WHEN created_at ），而 Navicat 同步只比对物理结构，完全忽略数据逻辑和执行顺序。
更麻烦的是：如果同步时勾选了“删除目标中不存在的对象”，可能把 Flyway 迁移新增的索引、触发器全干掉，且不会写入 flyway_schema_history，后续 flyway repair 或 validate 都会报错。
- 真正需要结构对比时，用
flyway info命令输出预期状态，再跟 Navicat 查出的实际结构人工比对 - Navicat 的“导出表结构为 SQL”功能可以辅助检查，但导出后务必核对
CREATE INDEX语句里的ON表名和字段顺序，Flyway 脚本里写的索引名可能被数据库自动截断（如 PostgreSQL 限制 63 字符），导致实际创建的名和脚本里写的不一致
实际操作中最容易被跳过的，是确认 flyway_schema_history 表所在的 schema 是否与连接默认 schema 一致，以及 checksum 失败时直接删表而不是走 repair。这两处一错，后面所有验证都建立在错误前提上。
