返回 Back English Version →

数据库迁移模式

中级 Intermediate 参考型 Reference ⚡ Claude Code 专属 ⚡ Claude Code Optimized
7 min read · 358 lines

生产级数据库迁移：零停机部署与扩展-收缩模式

数据库迁移模式

概述

面向生产系统的安全、可逆数据库模式变更最佳实践。涵盖 PostgreSQL、MySQL 及常用 ORM（Prisma、Drizzle、Django、TypeORM、golang-migrate）的迁移工作流，包括零停机部署（Zero-Downtime Deployment）策略和扩展-收缩模式（Expand-Contract Pattern）。

核心原则

  1. 每个变更都是一次迁移 — 永远不要手动修改生产数据库
  2. 生产环境只做前向迁移 — 回滚通过新的前向迁移实现
  3. 模式迁移和数据迁移分开 — 永远不要在一次迁移中混合 DDL 和 DML
  4. 对生产规模的数据测试迁移 — 在 100 行上正常的迁移在 1000 万行上可能导致锁表
  5. 已部署的迁移不可修改 — 永远不要编辑已在生产环境运行过的迁移

迁移安全检查清单

在应用任何迁移之前：

  • 迁移包含 UP 和 DOWN（或明确标记为不可逆）
  • 大表上不会产生全表锁（使用并发操作）
  • 新列有默认值或可为空（永远不要不带默认值添加 NOT NULL 列）
  • 索引并发创建（现有表不要内联在 CREATE TABLE 中）
  • 数据回填是独立于模式变更的单独迁移
  • 在生产数据副本上测试过
  • 回滚计划已记录

PostgreSQL 模式

安全添加列

-- 正确：可空列，不锁表
ALTER TABLE users ADD COLUMN avatar_url TEXT;

-- 正确：带默认值的列（Postgres 11+ 即时完成，不重写）
ALTER TABLE users ADD COLUMN is_active BOOLEAN NOT NULL DEFAULT true;

-- 错误：现有表上添加不带默认值的 NOT NULL（需要全表重写）
ALTER TABLE users ADD COLUMN role TEXT NOT NULL;
-- 这会锁表并重写每一行

无停机添加索引

-- 错误：大表上阻塞写入
CREATE INDEX idx_users_email ON users (email);

-- 正确：非阻塞，允许并发写入
CREATE INDEX CONCURRENTLY idx_users_email ON users (email);

-- 注意：CONCURRENTLY 不能在事务块内运行
-- 大多数迁移工具需要对此进行特殊处理

重命名列（零停机）

永远不要在生产环境直接重命名。使用扩展-收缩模式（Expand-Contract Pattern）：

-- 步骤 1：添加新列（迁移 001）
ALTER TABLE users ADD COLUMN display_name TEXT;

-- 步骤 2：回填数据（迁移 002，数据迁移）
UPDATE users SET display_name = username WHERE display_name IS NULL;

-- 步骤 3：更新应用代码，同时读写两个列
-- 部署应用变更

-- 步骤 4：停止写入旧列，删除旧列（迁移 003）
ALTER TABLE users DROP COLUMN username;

安全删除列

-- 步骤 1：移除应用中对该列的所有引用
-- 步骤 2：部署不包含该列引用的应用
-- 步骤 3：在下一次迁移中删除列
ALTER TABLE orders DROP COLUMN legacy_status;

-- Django 特殊处理：使用 SeparateDatabaseAndState 从模型中移除
-- 而不生成 DROP COLUMN（然后在下一次迁移中删除）

大规模数据迁移

-- 错误：在一个事务中更新所有行（锁表）
UPDATE users SET normalized_email = LOWER(email);

-- 正确：带进度的批量更新
DO $$
DECLARE
  batch_size INT := 10000;
  rows_updated INT;
BEGIN
  LOOP
    UPDATE users
    SET normalized_email = LOWER(email)
    WHERE id IN (
      SELECT id FROM users
      WHERE normalized_email IS NULL
      LIMIT batch_size
      FOR UPDATE SKIP LOCKED
    );
    GET DIAGNOSTICS rows_updated = ROW_COUNT;
    RAISE NOTICE '已更新 % 行', rows_updated;
    EXIT WHEN rows_updated = 0;
    COMMIT;
  END LOOP;
END $$;

Prisma（TypeScript/Node.js）

工作流

# 从模式变更创建迁移
npx prisma migrate dev --name add_user_avatar

# 在生产环境应用待执行的迁移
npx prisma migrate deploy

# 重置数据库（仅开发环境）
npx prisma migrate reset

# 模式变更后生成客户端
npx prisma generate

模式示例

model User {
  id        String   @id @default(cuid())
  email     String   @unique
  name      String?
  avatarUrl String?  @map("avatar_url")
  createdAt DateTime @default(now()) @map("created_at")
  updatedAt DateTime @updatedAt @map("updated_at")
  orders    Order[]

  @@map("users")
  @@index([email])
}

自定义 SQL 迁移

对于 Prisma 无法表达的操作（并发索引、数据回填）：

# 创建空迁移，然后手动编辑 SQL
npx prisma migrate dev --create-only --name add_email_index

-- migrations/20240115_add_email_index/migration.sql
-- Prisma 无法生成 CONCURRENTLY，所以手动编写
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email ON users (email);

Drizzle（TypeScript/Node.js）

工作流

# 从模式变更生成迁移
npx drizzle-kit generate

# 应用迁移
npx drizzle-kit migrate

# 直接推送模式（仅开发环境，无迁移文件）
npx drizzle-kit push

模式示例

import { pgTable, text, timestamp, uuid, boolean } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: uuid("id").primaryKey().defaultRandom(),
  email: text("email").notNull().unique(),
  name: text("name"),
  isActive: boolean("is_active").notNull().default(true),
  createdAt: timestamp("created_at").notNull().defaultNow(),
  updatedAt: timestamp("updated_at").notNull().defaultNow(),
});

Django（Python）

工作流

# 从模型变更生成迁移
python manage.py makemigrations

# 应用迁移
python manage.py migrate

# 显示迁移状态
python manage.py showmigrations

# 生成空迁移用于自定义 SQL
python manage.py makemigrations --empty app_name -n description

数据迁移

from django.db import migrations

def backfill_display_names(apps, schema_editor):
    User = apps.get_model("accounts", "User")
    batch_size = 5000
    users = User.objects.filter(display_name="")
    while users.exists():
        batch = list(users[:batch_size])
        for user in batch:
            user.display_name = user.username
        User.objects.bulk_update(batch, ["display_name"], batch_size=batch_size)

def reverse_backfill(apps, schema_editor):
    pass  # 数据迁移，不需要反向操作

class Migration(migrations.Migration):
    dependencies = [("accounts", "0015_add_display_name")]

    operations = [
        migrations.RunPython(backfill_display_names, reverse_backfill),
    ]

SeparateDatabaseAndState

从 Django 模型中移除列但不立即从数据库中删除：

class Migration(migrations.Migration):
    operations = [
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.RemoveField(model_name="user", name="legacy_field"),
            ],
            database_operations=[],  # 暂时不操作数据库
        ),
    ]

golang-migrate（Go）

工作流

# 创建迁移文件对
migrate create -ext sql -dir migrations -seq add_user_avatar

# 应用所有待执行的迁移
migrate -path migrations -database "$DATABASE_URL" up

# 回滚上一次迁移
migrate -path migrations -database "$DATABASE_URL" down 1

# 强制版本（修复脏状态）
migrate -path migrations -database "$DATABASE_URL" force VERSION

迁移文件

-- migrations/000003_add_user_avatar.up.sql
ALTER TABLE users ADD COLUMN avatar_url TEXT;
CREATE INDEX CONCURRENTLY idx_users_avatar ON users (avatar_url) WHERE avatar_url IS NOT NULL;

-- migrations/000003_add_user_avatar.down.sql
DROP INDEX IF EXISTS idx_users_avatar;
ALTER TABLE users DROP COLUMN IF EXISTS avatar_url;

零停机迁移策略

对于关键的生产变更，遵循扩展-收缩模式（Expand-Contract Pattern）：

阶段 1：扩展（EXPAND）
  - 添加新列/表（可空或带默认值）
  - 部署：应用同时写入新旧两处
  - 回填现有数据

阶段 2：迁移（MIGRATE）
  - 部署：应用从新处读取，同时写入两处
  - 验证数据一致性

阶段 3：收缩（CONTRACT）
  - 部署：应用只使用新的
  - 在单独的迁移中删除旧列/表

时间线示例

第 1 天：迁移添加 new_status 列（可空）
第 1 天：部署应用 v2 — 同时写入 status 和 new_status
第 2 天：运行回填迁移处理现有行
第 3 天：部署应用 v3 — 只从 new_status 读取
第 7 天：迁移删除旧的 status 列

反模式

反模式 失败原因 更好的做法
在生产环境手动执行 SQL 没有审计记录，不可重复 始终使用迁移文件
编辑已部署的迁移 导致环境间的漂移 创建新的迁移代替
不带默认值的 NOT NULL 锁表，重写所有行 先添加可空列，回填，再添加约束
大表上内联创建索引 在构建期间阻塞写入 使用 CREATE INDEX CONCURRENTLY
模式和数据在同一迁移中 难以回滚，事务时间长 分开成独立的迁移
在移除代码前删除列 应用在缺失列上报错 先移除代码，下次部署再删除列

核心原则： 每个数据库变更都应该是一次迁移。模式变更和数据变更分开处理。在生产规模数据上测试。已部署的迁移不可修改。对于关键变更使用扩展-收缩模式实现零停机。

相关技能 Related Skills

升级到 Prisma ORM 7（Upgrade to Prisma ORM 7）

Verified ⚡CC

Prisma 官方 v7 升级指南：破坏性变更 + 分步迁移 + ESM + 框架适配

流程型 Process 中级 Intermediate
prismaupgrademigration

Prisma CLI 命令参考（Prisma CLI Reference）

Verified ⚡CC

Prisma 官方 CLI 全命令参考：init/generate/migrate/dev + v7 配置变更

参考型 Reference 入门 Starter
prismaclidatabase

Prisma 客户端 API 参考（Prisma Client API Reference）

Verified ⚡CC

Prisma 官方 Client API：CRUD + 过滤器 + 关系查询 + 事务 + 聚合

参考型 Reference 中级 Intermediate
prismaclientcrud