Flyway 是什么：数据库迁移不是手动改 SQL
Flyway 是一个开源的数据库版本管理工具，核心作用是把数据库结构变更（比如建表、加字段、改索引）变成可版本化、可重复执行、可追溯的代码操作。它不替代你写 SQL，而是帮你管住这些 SQL 的执行顺序、执行环境和执行状态。
关键判断：如果你还在靠人工维护
init.sql、
v20240501_add_user_status.sql这类文件，并靠文档或记忆决定“哪个库跑过哪条”，那 Flyway 就是你要的自动化补丁管理器。
怎么初始化 Flyway 项目（以 Java + Maven 为例）
最常见踩坑点：只加依赖不配扫描路径，导致 migration 文件完全不生效。
在pom.xml中引入
flyway-core，版本建议用
9.22.3或更高（避免老版本对 MySQL 8.0+ 的
json类型支持问题） 确保 migration SQL 文件放在默认路径：
src/main/resources/db/migration/，命名必须符合格式：
V1__init_schema.sql、
V2__add_created_at_to_orders.sql配置
flyway.locations指向该路径（Spring Boot 中可在
application.yml写：
spring.flyway.locations=classpath:db/migration） 首次启动时，Flyway 会自动创建
flyway_schema_history表，记录每次执行的脚本版本、校验和、时间戳——这个表不能删，否则重放会失败
MySQL 下常见的 Flyway 错误和应对
错误不是 Flyway 本身坏了，而是它在严格执行约束。以下几种报错出现频率极高：
Validation failed: Migration checksum mismatch：说明某条已执行过的 SQL 被手动修改过。解决方式不是删记录，而是用
flyway repair命令重算校验和（仅限开发/测试环境）
Unable to obtain JdbcConnection：通常因 MySQL JDBC 驱动版本不匹配，比如用
mysql-connector-java:8.0.33连接 MySQL 5.7 时需显式加
?serverTimezone=UTC参数
SQL State: 45000 | Error Code: 1835（DDL inside stored routine）：某些 DDL（如
ALTER TABLE ... ALGORITHM=INSTANT）在低版本 MySQL 不被允许，得降级为
COPY或改用
flyway.placeholders动态替换
什么时候不该用 Flyway？
Flyway 管的是“结构演进”，不是数据搬运或业务逻辑。
大批量历史数据清洗（比如把百万行用户表按地区拆分）——这类应该用独立脚本 + 标记位控制，别塞进Vxxx迁移里 需要跨库同步 schema（比如从 MySQL 同步到 PostgreSQL）——Flyway 不做方言转换，
V1__create_table.sql里的
TINYINT(1)在 PG 里根本不存在 团队没有统一的 SQL 编码规范（例如有人用反引号包字段，有人不用），会导致 checksum 频繁不一致
真正难的从来不是加个依赖，而是让所有人写 SQL 时心里装着“这条语句未来要被重放十次”。
