数据库迁移
Database Migration
中级通用数据库迁移（Database Migration）是用可追踪的变更步骤，让数据库结构随产品版本演进。它解决了开发、测试和线上数据库结构不一致的问题，例如给已有用户表增加一个可为空的昵称字段。
你可能会说：「网站要加一个昵称字段，怎么让测试库和线上库都安全地跟上这次改动？」
动手看看给用户资料加昵称
1
产品要支持昵称，我们把“给用户表加一个可空昵称字段”写成迁移 M001。工具先在开发库执行，成功后记录版本。
要点数据库迁移是怎样完成一次改动的？
- 1
把结构变化写成迁移文件
比如我们给用户表加昵称字段，就把新增字段的操作写进迁移文件，而不是只在自己的数据库里手动改。这样同事和部署流程才能执行同一份变更。
- 2
记录哪些变更已经执行
迁移工具通常会记录每个数据库执行到了哪一步。你在测试环境跑过新增字段，不代表线上也跑过；分别记录进度，才能让各环境按顺序补上缺少的变更。
- 3
让旧数据和新代码接得上
已有用户没有昵称，所以直接加一个不允许为空的字段可能会失败。我们可以先加可为空字段，再逐步填充数据、调整代码；等数据齐了，再考虑加上非空限制。
容易混淆的地方
数据库迁移不等于把数据库搬到另一台服务器：后者关注数据放在哪里，这里的迁移主要关注结构如何随版本改变。它也不等于日常写入数据；用户改昵称是业务操作，给用户表新增昵称字段才是典型的迁移。迁移可以包含数据调整，但前提是这项调整服务于版本变更。
什么时候用
适合用
- 网站上线用户昵称功能，需要给已有用户表增加字段，并让测试库和线上库按相同顺序更新。
- 后台要把一个旧字段拆成两个新字段，需要分阶段调整表结构、搬移已有数据，再更新读取逻辑。
- 团队多人开发同一个产品，需要把各自的数据库结构变更纳入代码仓库，方便新环境复现。
不适合用
- 只是修改某位用户的昵称，数据库结构没变；让应用执行普通的更新操作即可。
- 只是把线上数据复制到测试环境供排查使用；用经过脱敏的数据导出、导入或备份恢复更合适。
- 只是想把数据库服务迁到另一台机器，表结构和应用版本都不变；重点是数据复制与切换方案。
练一练选一个答案，看看解释
你的 App 已有十万条用户记录，现在要上线昵称功能。AI Agent 提议给用户表新增一个必填昵称字段，并让新版代码立刻读取它。你会选哪种做法？
让 AI 帮你做复制给 AI Agent 直接用
请为用户昵称功能设计数据库迁移：检查现有用户表和历史数据，先给出兼容旧数据的字段变更与数据填充步骤，再说明应用代码如何分阶段切换。生成迁移文件和验证方法，并指出哪些操作回滚时可能丢失数据；先不要执行线上变更。