Schema 是声明,Migration 是历史

**`schema.prisma` 只是「目标结构长什么样」的声明,它不会可靠地把生产库改好;真正把数据库改到那个结构的是版本化的 migration 历史。** 只有 schema 没有 migration,等于「代码完成」但不「可部署」。

两者的分工

schema.prisma  ──(migrate dev)──▶  migration.sql  ──(migrate deploy)──▶  生产库
  • Schema:有哪些表、字段、类型、默认值、关系、唯一约束与索引、要生成哪些客户端 API。
  • Migration:目录形式的变更历史,每个目录里是明确的 SQL。部署时按顺序只执行尚未执行的,执行记录存在数据库自己的迁移表里。

db push 与 migrate deploy 不能混用

db pushmigrate deploy
依据当前 schema已提交的 migration
版本历史无有,可审查、可回放
风险可能删除/重建/重命名字段有明确顺序
适用临时、本地、可销毁的库Preview / Staging / Production

已有生产库接 migration 的顺序

不能直接生成 migration 了事,要先做 baseline:核对生产/预览库的真实结构 → 备份并检查 drift → 为现有库设计基线 → 再生成增量 migration → 在独立分支库上验证 → 最后才应用。测试脚本也要从 db push 改成临时库上的 migrate deploy,否则测试永远验证不到真实迁移路径。

相关