SQL Liquibase 的 tag 与 changeset 的版本标记回滚实践

liquibase 的 tag 是数据库状态快照标记，changeset 是不可变变更单元；回滚依赖 rollback 命令配合 tag 或时间点，需每个 changeset 明确定义 rollback 逻辑且不修改已部署 changeset。

Liquibase 的 tag 和 changeset 版本标记不是同一类机制，但协同使用可支撑可控回滚。tag 是对某次 update 执行后数据库状态的快照标记，不改变 changeset 本身；changeset 则是不可变的变更单元，靠 id/author/filepath 唯一标识。真正支持“按版本回滚”的核心是 rollback 命令配合 tag 或标签范围，而非修改或删除已部署的 changeset。

用 tag 标记关键发布节点

在每次上线完成、验证通过后，立即打 tag，相当于给数据库状态拍一张“可信快照”：

• 执行 liquibase tag v1.2.0（建议用语义化版本号）
• tag 名称区分大小写，且不能含空格或特殊字符（如 v1.2.0-rc1 合法，v1.2.0 rc1 会报错）
• tag 仅记录当前 DATABASECHANGELOG 表中最新一条记录的 datetime 和 author 等上下文，不保存数据或结构副本
• 一个数据库可有多个 tag，但同一名称只能存在一个——重复执行会覆盖原 tag 时间戳

基于 tag 回滚到指定状态

回滚操作本质是逆向执行自目标 tag 之后部署的所有 changeset（前提是每个 changeset 都定义了 rollback）：

• liquibase rollback v1.1.0：回滚到 tag v1.1.0 对应的状态（不含该 tag 之后的任何 changeset）
• liquibase rollbackCount 3：回滚最近 3 个 changeset（不依赖 tag，但需确保它们都支持 rollback）
• liquibase rollbackToDate "2024-05-20T14:30:00"：回滚到指定时间点前的状态（精度为秒，依赖 DATABASECHANGELOG 中的 DATEEXECUTED 字段）
• 注意：rollback 不会删除已打的 tag，也不会影响更早的 tag；它只修改数据库结构/数据，并更新 DATABASECHANGELOG 表中的 MD5SUM 和 ROLLBACK 相关字段

changeset 的版本控制与 rollback 编写要点

changeset 本身没有“版本号”，其稳定性依赖唯一性 + 显式 rollback 定义。若未提供 rollback 逻辑，对应 changeset 就无法参与 tag 回滚流程：

• 推荐始终使用 <rollback></rollback> 标签（xml）或 //rollback 注释（sql 格式），哪怕只是 DROP table 或 delete FROM xxx WHERE ...
• 避免使用 validCheckSum 或手动修改 MD5SUM 绕过校验——这会破坏 Liquibase 的完整性保护，导致后续 update 失败
• SQL changeset 中，若含多条语句，请用 --rollback 精确标注每条 rollback 语句位置，Liquibase 按注释块解析，不依赖顺序猜测
• 对于无法自动逆向的操作（如 INSERT INTO config VALUES ('new_feature', 'on')），应在 rollback 中补充业务判断逻辑（例如加 WHERE 条件限定删除范围）或改用 preConditions 控制执行前提

生产环境回滚的实用建议

真实场景中，单纯依赖 tag rollback 往往不够，需结合流程与防护措施：

• 在 CI/CD 流水线中，将 liquibase tag 作为部署成功的最后一个步骤，并同步记录 git commit hash 与 tag 关系
• 回滚前务必先执行 liquibase futureRollbackSQL --tag v1.1.0，生成预览脚本，人工审查逻辑是否安全（尤其涉及 DROP、TRUNCATE、DELETE）
• 禁止在生产库直接运行无预览的 rollback；高危操作建议搭配备份快照（如 mysqldump / pg_dump）再执行
• 若某次发布包含多个相互依赖的 changeset，但只想回滚其中一部分，应避免使用 tag rollback，改用 rollbackOneChangeSet 并精确指定 id+author+filepath