数据库结构版本管理
为什么数据库也需要版本管理？ 假设你开发新功能时，在本地执行了： ALTER TABLE users ADD COLUMN nickname VARCHAR(100); 代码提交并部署到测试环境后，接口却报错： column "nickname" does not exist 原因很简单：代码进入了 Git，修改数据库的 SQL 却只存在于你的电脑里。 如果数据库变更依靠聊天记录或人工执行，我们就很难回答： 哪些环境执行过这条 SQL？ 新环境应该按什么顺序初始化？ 测试库和生产库的结构是否一致？ 三个月前为什么增加了这个字段？ 解决办法是 DB Migration（数据库迁移）：把每次数据库结构变化写成带版本号的文件，提交到 Git，再由工具按顺序执行。 Migration 是怎样工作的？ 可以把 Migration 理解成“数据库的 Git Commit”： 20260724100000 创建 users 表 20260724103000 增加 nickname 字段 20260724110000 创建邮箱索引 迁移工具会： 读取 Migration 目录； 查询数据库已经执行的版本； 按顺序执行尚未执行的文件； 记录成功执行的版本。 几个容易混淆的概念： 概念 用途 Migration 记录数据库如何一步步变化 Schema 快照 展示数据库当前的完整结构 数据备份 在数据损坏或丢失后恢复 Migration 不能代替备份。执行 DROP COLUMN 后，Down Migration 也不一定能找回已经删除的数据。 ORM 自动建表也不完全等于版本管理。ORM 可以帮助生成 Migration，但共享环境最好执行已经生成、评审并提交到 Git 的确定性 SQL，而不是在应用启动时临时修改数据库。 ...