数据库版本怎么管理好

数据库版本管理（通常叫 Database Versioning / Migration Management）是研发和运维中很容易踩坑、但又非常关键的一环。下面从「原则 → 工具 → 实践」三个层面给你一套靠谱的做法。

一、核心原则（先对齐认知）

1. 数据库结构也是代码

   • 表结构、索引、视图、存储过程，都要进 Git
   • 不能“手动在线上改一下”

2. 变更可追溯、可回滚

   • 每一次变更都有版本号
   • 能向前（升级），也能向后（回退）

3. 环境一致性

   • 开发 / 测试 / 预发 / 生产，结构必须一致
   • 用同一套迁移脚本生成

4. 禁止直接人工改生产库

   • 所有变更走流程 + 脚本 + 审核

二、主流管理方式（推荐）

✅ 方式一：Migration 脚本（最推荐）

核心思想：用“增量脚本”管理数据库版本

常见工具

示例（Flyway）

db/
 ├── V1__init_schema.sql
 ├── V2__add_user_table.sql
 ├── V3__add_index.sql

• V1, V2 是版本号
• 工具自动记录“已执行到哪一步”
• 新环境直接跑全部脚本即可

✅ 优点：清晰、可控、可审计
❌ 缺点：需要规范约束

✅ 方式二：Schema as Code（偏现代）

• 用代码描述“目标结构”
• 工具自动 diff 并生成变更

例如：

• Prisma
• Django ORM
• Entity Framework

model User {
  id   Int    @id @default(autoincrement())
  name String
}

✅ 适合业务系统
❌ 复杂迁移（数据迁移）不够灵活

三、落地最佳实践（非常重要）

1️⃣ 每个变更一个小文件

• 不要“一个大 SQL 改半年”
• 一个 PR = 一个迁移

2️⃣ 只增不删（兼容性原则）

• ❌ 直接删列
• ✅ 先标记 deprecated → 下个版本再删

3️⃣ 数据迁移要单独写

-- 结构变更
ALTER TABLE user ADD age INT;

-- 数据填充
UPDATE user SET age = 18 WHERE age IS NULL;

4️⃣ 每次发版前跑校验

• CI 中自动执行 migration
• 防止“本地能跑，线上炸”

5️⃣ 生产变更要有回滚脚本

V3__add_index.sql
V3_rollback__drop_index.sql

四、常见错误（避坑）

❌ 用 Navicat 手动改生产
❌ 多人同时改同一张表，冲突没人发现
❌ 迁移脚本里写死环境数据
❌ 不备份就跑 migration

五、简单推荐方案（按场景）

• 小团队 / 创业：Flyway + Git
• 业务系统：ORM + Migration
• 多语言公司：Liquibase
• 云原生：结合 CI/CD + DB Migration Job

如果你愿意，可以告诉我：

• 用的什么数据库（MySQL / PG / Oracle）
• 技术栈（Java / Python / Node / Go）
• 团队规模

我可以直接给你一套可落地的版本管理方案 + 目录结构 + CI 示例。