Schema 是声明,Migration 是历史
两者的分工
schema.prisma ──(migrate dev)──▶ migration.sql ──(migrate deploy)──▶ 生产库
- Schema:有哪些表、字段、类型、默认值、关系、唯一约束与索引、要生成哪些客户端 API。
- Migration:目录形式的变更历史,每个目录里是明确的 SQL。部署时按顺序只执行尚未执行的,执行记录存在数据库自己的迁移表里。
db push 与 migrate deploy 不能混用
db push | migrate deploy | |
|---|---|---|
| 依据 | 当前 schema | 已提交的 migration |
| 版本历史 | 无 | 有,可审查、可回放 |
| 风险 | 可能删除/重建/重命名字段 | 有明确顺序 |
| 适用 | 临时、本地、可销毁的库 | Preview / Staging / Production |
已有生产库接 migration 的顺序
不能直接生成 migration 了事,要先做 baseline:核对生产/预览库的真实结构 → 备份并检查 drift → 为现有库设计基线 → 再生成增量 migration → 在独立分支库上验证 → 最后才应用。测试脚本也要从 db push 改成临时库上的 migrate deploy,否则测试永远验证不到真实迁移路径。
相关
- 数据权威模型要先于同步与迁移确定 —— 迁移之前先确定谁是权威
- 存量不会自动跟上新逻辑 —— 迁移就是「把存量带过来」的正式手段
- 改远端库结构前先确认库身份与回滚 —— 动生产结构前的确认项
- 功能缺失先确认运行的是哪份产物 —— 同一取向:先确认生效的是哪一份