如何合并Liquibase变更文件以匹配当前数据库状态

导出全量脚本合并方案的可行性 #

你提到的从SQL Server导出全量对象生成脚本替代零散变更文件的方案是完全可行的，这是Liquibase场景下解决历史变更集过多、维护成本过高问题的标准操作，业内一般称为「基准线重置」。

操作的前提条件 #

执行合并前必须先确认两个核心条件，避免后续出现环境不一致问题：

• 所有开发、测试、生产环境的数据库schema已经完全同步，不存在未执行的历史变更集
• 已完整备份所有环境的数据库、旧版DbChangeLog.xml以及整个ChangeSetScripts目录，归档留存以便回溯

具体操作步骤 #

1. 核对所有环境的DATABASECHANGELOG系统表内容，确认所有历史变更的执行状态完全一致，无环境差异
2. 从生产环境导出完整的schema生成脚本，包含表、索引、约束、存储过程、自定义类型、函数等所有业务对象，导出后先在空白SQL Server实例上执行验证，确保无依赖报错、可以完整初始化整套schema，将验证通过的脚本保存为单个文件如full_schema_baseline_2024xxx.sql
3. 归档旧的变更文件和changelog，不要直接删除
4. 新建空白的DbChangeLog.xml，仅添加一个指向全量脚本的changeSet，示例配置如下：

<changeSet author="baseline" id="full_schema_2024xxx">
    <sqlFile endDelimiter="\nGO" path="full_schema_baseline_2024xxx.sql" relativeToChangelogFile="true" splitStatements="true" stripComments="false" />
    <rollback />
</changeSet>

5. 在所有现有环境执行liquibase changelog-sync命令，该命令会将新的基准线changeSet标记为已执行，不会在现有环境重复跑全量脚本；后续新的变更还是按照你原来的流程添加即可

其他可选优化方案 #

如果不想做全量合并，也可以用拆分changelog的方式解决文件臃肿问题：将历史变更按年份/业务模块拆分为多个子changelog文件，主DbChangeLog.xml仅用include标签引入子changelog即可，示例如下：

<include file="changelogs/2022_changelog.xml" relativeToChangelogFile="true"/>
<include file="changelogs/2023_changelog.xml" relativeToChangelogFile="true"/>
<include file="changelogs/2024_changelog.xml" relativeToChangelogFile="true"/>

这种方案不需要做基准线同步操作，也能大幅降低单个changelog的维护难度。

注意事项 #

• 全量基准线不需要频繁重置，一般1~2年操作一次即可，过于频繁反而会提升环境不一致的风险
• 导出全量脚本时要注意处理对象的依赖顺序，避免出现先创建外键、后创建关联表这类顺序错误
• 如果需要保留基准线的回滚能力，可以提前导出一份当前版本的空库备份作为回滚方案，比编写全量回滚SQL效率更高

内容的提问来源于stack exchange，提问作者Robur_131