FlywayDB 是一款 开源数据库版本管理工具，开发中将表结构的变更或数据初始化脚本维护好，更新到测试环境或线上发版启动服务的时候，会检测版本号自动执行数据库变更，可以减少每次发版到其他环境的人工执行操作。

工作流程

• 初始化阶段
  首次运行时检查目标数据库是否存在 flyway_schema_history 表，不存在则创建。

• 脚本扫描与版本比对
  默认扫描 classpath:db/migration 目录下的脚本（可配置），按版本号排序后与历史表比对。
  版本号规则： V<版本号>__<描述>.sql，版本号需唯一且递增，否则报错。
  版本号建议使用时间戳或递增数字，如V20230701__description.sql

• 迁移执行
  对比历史表后，执行未应用的脚本，并记录版本、校验和等信息到元数据表。
  使用 CRC32 算法校验脚本内容，防止篡改。

• 锁机制
  通过数据库排他锁（如 SELECT ... FOR UPDATE）协调多节点并发执行，确保迁移原子性。

项目集成

1. 添加依赖

<dependency><groupId>org.flywaydb</groupId><artifactId>flyway-core</artifactId>
</dependency>

2. Nacos配置

spring:flyway:enabled: truelocations: classpath:db/updatevalidate-on-migrate: trueencoding: UTF-8#    placeholders:#      table-prefix: "test_"baseline-on-migrate: true  # 对非空数据库首次使用时设为true#    baseline-version: "20250701"      # 基线版本号table: table_update_history  # 使用自定义表名out-of-order: false  # 生产环境必须按顺序执行

这里以项目下3个脚本为例，先插入一张新表，然后分别插入1月到3月、4月到6月的数据，数据库中没有这张表。
项目启动完会看到库里多了event_tracking表，插入了两个脚本初始化的数据。

同时会按配置生成表变更记录，维护脚本变更版本号。

这里有几点要注意：

• 如果数据库用户没有建表权限，则需要管理员提前创建；
• 表结构需符合Flyway要求；
• 如果使用多个数据源，需要为每个数据源配置单独的Flyway实例，每个实例会维护自己的历史表；
• 可以配置clean-on-validation-error: true便于调试，但生产环境必须禁用此选项；
• 如果项目组开发人员比较多，有些迭代版本开发周期比较长，之前开发定义好的版本号，在开发环境执行没问题，等测完真正发版的时候，版本号可能不是最大的（中间有其他开发先发版），这时需要重新维护版本号；