Flyway 工作原理：迁移机制、版本号解析、校验与修复、基线版本

Flyway 的核心设计理念是“约定优于配置”，通过一套标准化的迁移文件命名规则和版本号解析逻辑，自动管理数据库模式的演进。理解其底层工作原理，是构建可靠数据库迁移架构的前提。

2.1 迁移机制：状态机与元数据表

Flyway 在目标数据库中维护一张名为 flyway_schema_history 的元数据表（默认名称，可配置），用于记录所有已执行的迁移记录。每次执行迁移时，Flyway 会执行以下状态机流程：

1. 扫描：读取文件系统或类路径下的所有迁移脚本。
2. 比对：将扫描到的脚本版本号与 flyway_schema_history 表中的已执行记录进行比对。
3. 校验：对已执行过的脚本进行 checksum 校验，确保未被篡改。
4. 执行：按版本号升序执行所有未应用的迁移脚本。
5. 记录：将每次成功执行的迁移信息写入元数据表。

2.2 版本号解析：命名规范与排序规则

Flyway 通过文件命名来识别迁移脚本的版本号和类型。标准命名格式如下：

前缀 + 版本号 + 分隔符 + 描述 + 后缀

示例：
V1__create_user_table.sql
V2.1__add_email_column.sql
V3.0.1__insert_initial_data.sql
R__daily_cleanup_view.sql  （可重复迁移，无版本号）

2.3 校验与修复：Checksum 机制与修复策略

Flyway 在每次执行 migrate 或 validate 命令时，会对所有已执行过的迁移脚本重新计算 CRC32 checksum，并与元数据表中存储的原始值进行比对。如果发现不一致，Flyway 会抛出校验失败异常并阻止迁移继续执行。

修复策略：

• 手动修复：在元数据表中删除或修改对应记录（仅限紧急情况，不推荐）。
• Flyway repair 命令：自动清除失败的迁移记录，并将已执行脚本的 checksum 重新对齐到当前文件内容。
• 最佳实践：永远不要修改已执行过的迁移脚本；如需变更，应创建新的迁移版本。

# 修复命令示例
flyway repair

# 修复操作包括：
# 1. 删除所有失败的迁移记录（success=0）
# 2. 重新对齐已成功迁移的 checksum 值
# 3. 移除已删除迁移脚本对应的历史记录

2.4 基线版本：从非空数据库开始

当 Flyway 首次应用于一个已有表结构的数据库时，需要设置基线版本（Baseline）。基线版本告诉 Flyway：“这个数据库已经处于某个版本状态，不要尝试执行比这个版本更早的迁移脚本。”

基线版本的工作流程：

1. 执行 flyway baseline 命令，指定基线版本号（如 1.0）。
2. Flyway 在元数据表中插入一条基线记录，标记当前数据库状态。
3. 后续执行 flyway migrate 时，只会执行版本号大于基线版本的迁移脚本。

2.5 迁移类型对比总结