89、数据库版本管理：Liquibase/Flyway集成、版本回滚、变更脚本管理

说实话，做了这么多年嵌入式数据库开发，我见过太多因为数据库版本混乱导致的线上事故了。有一次，一个同事直接在生产库上手动执行了一条ALTER TABLE，结果和代码里的实体类对不上，整个服务启动就报错。嗯，从那以后，我就把数据库版本管理当成了项目的「安全带」——平时觉得多余，关键时刻能救命。

今天咱们聊聊两个主流工具：Liquibase 和 Flyway。说白了，它们就是帮你把数据库的每一次变更都记录下来，像Git管理代码一样管理你的数据库结构。

为什么需要数据库版本管理？

你想想看，代码有Git，前端有npm，但数据库呢？很多人还在靠「跑一个SQL脚本」来更新。团队里两个人同时改了表结构，谁先跑谁后跑？跑错了怎么回滚？

我个人习惯把数据库变更脚本当成「一等公民」对待。每次修改表结构、加索引、改存储过程，都写成一个版本化的脚本。这样有几个好处：

  • 可追溯：谁在什么时间改了什么东西，一目了然
  • 可回滚：出问题了，一键回到上一个版本
  • 可重复：新同事拉下代码，跑一遍脚本就能得到和线上一样的库

核心思想：数据库的每一次变更，都应该像代码提交一样有版本号、有作者、有描述。

Flyway：轻量级的选择

Flyway 是我用得比较多的工具，尤其适合嵌入式场景。它轻量、简单，不需要额外装服务端。它的工作方式其实很朴素：

  1. 在数据库里建一张表叫 flyway_schema_history
  2. 每次执行脚本时，检查这张表里有没有执行过
  3. 没执行过的，按版本号顺序执行

来看一个实际例子。假设我有一个C语言写的嵌入式设备，数据库用的是SQLite。我想集成Flyway，怎么做？

// 伪代码：C语言中调用Flyway命令行工具
#include <stdlib.h>

int run_flyway_migration() {
    // 执行迁移脚本
    int ret = system("flyway migrate -url=jdbc:sqlite:device.db"
                     " -locations=filesystem:./migrations");
    if (ret != 0) {
        fprintf(stderr, "迁移失败，请检查脚本\n");
        return -1;
    }
    return 0;
}

int rollback_to_version(const char* version) {
    // 回滚到指定版本
    char cmd[256];
    snprintf(cmd, sizeof(cmd),
             "flyway undo -url=jdbc:sqlite:device.db -targetVersion=%s",
             version);
    return system(cmd);
}

小提示：在嵌入式设备上，如果资源受限，可以考虑用Flyway的Java库或者Go版本的实现。我曾在ARM Cortex-A7上跑过，内存占用不到20MB，完全没问题。

Liquibase：更灵活的变更管理

Liquibase 和 Flyway 最大的区别在于：它用XML/YAML/JSON来描述变更，而不是直接用SQL。这样做的好处是——跨数据库兼容性更好。你写一套变更描述，可以同时生成MySQL、PostgreSQL、SQLite的SQL。

我个人觉得，如果你的项目需要支持多种数据库，Liquibase 是更好的选择。来看一个XML格式的变更集：

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
        http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">

    <changeSet id="1" author="zhangsan">
        <comment>创建设备信息表</comment>
        <createTable tableName="device_info">
            <column name="id" type="int" autoIncrement="true">
                <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="device_name" type="varchar(100)">
                <constraints nullable="false"/>
            </column>
            <column name="firmware_version" type="varchar(20)"/>
            <column name="created_at" type="timestamp"/>
        </createTable>
    </changeSet>

    <changeSet id="2" author="lisi">
        <comment>添加设备状态字段</comment>
        <addColumn tableName="device_info">
            <column name="status" type="int" defaultValue="0">
                <constraints nullable="false"/>
            </column>
        </addColumn>
    </changeSet>
</databaseChangeLog>

注意：Liquibase的XML变更集虽然灵活，但写起来比纯SQL啰嗦。我建议在团队里统一风格——要么全用XML，要么全用SQL，别混着来，否则维护起来很痛苦。

版本回滚：怎么安全地「后悔」？

回滚是数据库版本管理里最容易被忽视的部分。很多人只写了「向上迁移」的脚本，没写「向下回滚」的脚本。我曾经吃过这个亏——有一次上线后发现新加的字段导致旧代码崩溃，想回滚却发现没有回滚脚本，只能手动写SQL恢复，折腾了两个小时。

我的建议是：每个变更脚本，都必须配套一个回滚脚本。

Flyway 的回滚脚本命名规则是：V1__description.sql 对应 U1__description.sql（U代表Undo）。Liquibase 则直接在changeSet里加 <rollback> 标签。

-- 迁移脚本：V2__add_column_status.sql
ALTER TABLE device_info ADD COLUMN status INTEGER DEFAULT 0;

-- 回滚脚本：U2__add_column_status.sql
ALTER TABLE device_info DROP COLUMN status;

经验之谈：回滚脚本一定要在测试环境验证过。我见过有人写的回滚脚本语法错误，真到用的时候跑不了，那就尴尬了。

变更脚本管理的最佳实践

说了这么多，总结几条我这些年积累下来的经验：

  • 脚本命名要规范：建议用 V{版本号}__{描述}.sql 格式，版本号用时间戳或递增数字，避免冲突
  • 一个脚本只做一件事：别把建表和加索引写在一个脚本里，出了问题不好定位
  • 脚本要幂等：同一个脚本跑两次，结果应该一样。比如用 IF NOT EXISTS 或 CREATE OR REPLACE
  • 版本号不要跳跃：别从V1直接跳到V5，中间留空容易让人困惑

下面这张图展示了整个数据库版本管理的核心流程：

数据库版本管理核心流程 编写变更脚本 本地测试验证 提交到版本库 CI自动执行迁移 集成测试验证 生产环境部署 异常回滚 回滚到上一个稳定版本 开发阶段 CI/CD阶段 生产部署

在C语言项目中集成

很多做嵌入式C开发的朋友会问：Flyway和Liquibase都是Java工具，C语言怎么用？其实很简单——把它们当作命令行工具调用就行。

我一般会在项目的 Makefile 里加一个 db-migrate 目标：

# Makefile 示例
DB_URL = jdbc:sqlite:build/device.db
MIGRATIONS_DIR = migrations

db-migrate:
    flyway -url=$(DB_URL) -locations=filesystem:$(MIGRATIONS_DIR) migrate

db-rollback:
    flyway -url=$(DB_URL) -locations=filesystem:$(MIGRATIONS_DIR) undo

db-info:
    flyway -url=$(DB_URL) info

.PHONY: db-migrate db-rollback db-info

然后在C代码的初始化函数里，启动时自动检查并执行迁移：

int database_init(const char* db_path) {
    // 1. 打开数据库
    sqlite3* db;
    int rc = sqlite3_open(db_path, &db);
    if (rc != SQLITE_OK) {
        fprintf(stderr, "无法打开数据库: %s\n", sqlite3_errmsg(db));
        return -1;
    }

    // 2. 检查schema版本
    int current_version = get_schema_version(db);
    int target_version = get_latest_migration_version();

    if (current_version < target_version) {
        printf("数据库需要升级: %d -> %d\n",
               current_version, target_version);
        // 3. 调用外部迁移工具
        system("make db-migrate");
    }

    sqlite3_close(db);
    return 0;
}

小技巧：在嵌入式设备上，如果不想依赖Java运行时，可以考虑用Go语言重写一个轻量级的迁移工具。我做过一个项目，把Flyway的核心逻辑用C语言重新实现了一遍，只支持SQLite，整个工具编译出来不到500KB。

避坑指南

最后，分享几个我踩过的坑：

  • 不要在生产库上直接测试回滚：我曾经在预发布环境测试回滚，结果回滚脚本写错了，把整个表删了。还好有备份，不然就凉了。
  • 版本号冲突问题：两个人同时提交了V3脚本，合并时冲突了。我的做法是：用时间戳做版本号，比如 V202401011200__add_index.sql，基本不会冲突。
  • 大表迁移要小心：给几百万行的表加索引，直接跑ALTER TABLE可能会锁表很久。我建议用 CREATE INDEX CONCURRENTLY（PostgreSQL）或者分批处理。
  • 别忘了备份：任何迁移操作之前，先备份数据库。哪怕是一个简单的加字段操作，也值得备份。我见过加字段导致磁盘满的案例。

好了，关于数据库版本管理，今天就聊到这儿。记住一句话：没有版本管理的数据库，就像没有刹车的车——你敢开，我不敢坐。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →