17370845950

Flyway 默认不支持 XML 迁移脚本，仅原生识别 SQL 和 Java 文件；因其设计强调简单、可靠、可审计，而 XML 缺乏标准迁移语义且无内置解析器。

Flyway 默认不支持 XML 格式的迁移脚本，它原生只识别 SQL（.sql） 和 Java（.java） 两类迁移文件。XML 文件（如 .xml）会被 Flyway 忽略，不会被扫描、解析或执行。

为什么 Flyway 不支持 XML 迁移脚本

Flyway 的设计哲学是“简单、

可靠、可审计”——SQL 脚本直观、数据库无关性可控、版本回溯清晰。XML 通常用于配置或描述性内容（比如 MyBatis 的 mapper），不是标准的数据库变更载体。Flyway 没有内置 XML 解析器，也不定义 XML 的迁移语义（比如哪个标签代表 CREATE、哪个代表 INSERT），因此无法直接运行 XML 作为 migration。

如果非要使用 XML 文件做数据库变更，可行方案

你不能让 Flyway 直接执行 XML，但可以绕过限制，把 XML 内容“转化”为 Flyway 能识别的形式：

• 方案一：用 XML 存储 SQL 片段，再由构建工具（如 Maven）预处理生成 .sql 文件
  例如，写一个 changelog-v1.xml，里面用自定义结构存 DDL：
  CREATE TABLE user (id BIGINT PRIMARY KEY);
  配合 Maven 插件（如 `xml-maven-plugin` 或自定义 Groovy 脚本）在编译前解析该 XML，输出对应 V1__create_user_table.sql 到 src/main/resources/db/migration/，再交由 Flyway 执行。
• 方案二：用 Java Migration 封装 XML 解析逻辑
  编写一个 Java 迁移类（实现 JavaMigration 接口），在 migrate() 方法中读取 classpath 下的 XML 文件，用 DOM/SAX/JAXB 解析出 SQL 语句，再通过 JdbcTemplate 或 Connection 执行。注意：需自行保证语句顺序、事务边界和幂等性。
• 方案三：放弃 Flyway，换用支持 XML 的工具（不推荐）
  如 Liquibase 原生支持 XML/YAML/JSON 格式的 changelog（databaseChangeLog）。但切换意味着重构迁移历史、适配新语法、重新学习运维方式，通常得不偿失。

更推荐的做法：坚持用标准 SQL 脚本

绝大多数场景下，直接写 SQL 更安全高效：

• 文件名遵循 Flyway 命名规范（如 V1__init_schema.sql、V2__add_email_to_user.sql）
• SQL 内容保持纯 DDL/DML，避免数据库特有语法（或用 /* +flyway:sql */ 注释标注方言）
• 复杂逻辑（如批量插入、条件判断）可用存储过程 + SQL 调用，或拆成多个小迁移
• 若需复用 SQL 片段，可用构建时模板引擎（如 FreeMarker）生成最终 .sql 文件

不复杂但容易忽略：Flyway 的能力边界很明确——它不是通用脚本引擎，而是专注数据库版本控制的轻量工具。用对格式，才能少踩坑。