数据与存储
数据库迁移Migration
你可能会问
数据库迁移到底是什么？直接登上数据库改表结构，不行吗？
简单来说
以可追踪的方式修改数据库结构，并让不同环境保持一致。
登上数据库直接改写成 003 号迁移同一个改动，两种下场
其他环境不知情每个环境自动追平有账可查，才敢改结构
01 · 先这样理解
把抽象概念放进真实场景
以可追踪的方式修改数据库结构，并让不同环境保持一致。
换个角度想Migration 像装修的变更单：每次改水电都开一张编号单据，哪套房子（环境）施工到第几号一目了然。口头喊师傅「顺手改一下」，改过什么、别的房子改没改，事后谁都说不清。
02 · 点击演示
users 表要加一列，怎么改才不出事故？
突出显示的部分，就是当前概念在整条流程中负责的位置。
- 新需求
功能支持手机号登录前提users 表加 phone 列 打开数据库控制台，手动 ALTER TABLE
敲完就完了，没留任何记录
003_add_phone.sqlup给 users 加 phone 列down删掉 phone 列（回退用）只有你连的那个库变了
本地 ✓ · 测试 ✗ · 同事本地 ✗
部署时按编号执行测试环境✓ 已跑到 003生产环境✓ 已跑到 003- 事故现场线上没这列，接口 500；想回退，全凭回忆改了什么、在哪改的，只有你知道有备无患出问题按 down 脚本撤销，环境永远对得上结构变化有版本，才敢放心改
1 / 4
Change · 结构需要变化
03 · 放进真实任务
什么时候会遇到它
多环境一致
「本地能跑、线上报错」的结构漂移，靠迁移按序执行来杜绝。
团队同步
同事拉取代码后跑一下迁移，数据库就追平了，不用口头交代。
变更可追溯
每次结构改动都有编号、说明和时间，出问题能定位到某一号。
04 · 想一想
用一个问题检查理解
AI 直接连上数据库，帮你把一个列改了名。功能一切正常，这样做的隐患是什么？
查看答案
这次改动没留下任何脚本：测试环境、同事的本地库都不知道这回事，下次部署两边就对不上；出问题也没有回退依据。应该让 AI 把改动写成迁移脚本，再由各环境按序执行。
最容易踩的坑
迁移改的是真实数据的结构，删列、改类型可能造成数据丢失。生产环境执行前要有备份，破坏性改动先在测试环境演练一遍。