执行数据库迁移的三种路径

迁移的本质

数据库迁移不是技术问题，是时间问题。

每次 schema 变更都是一个时间点。表结构、索引、约束——这些定义了数据在某个时刻的形态。迁移就是让数据库从一个时间点移动到另一个时间点。

问题不在于"如何变更"，而在于"谁来控制这个变更过程"。

CLI：本地控制的精确性

用命令行工具（如 Prisma、TypeORM、Drizzle）执行迁移，核心优势是控制权在你手里。

每条迁移都是一个文件。你能看到它，修改它，版本控制它。运行 npx prisma migrate deploy 时，你知道它会执行哪些 SQL。如果有问题，你能回滚。

CLI 迁移强制你思考顺序。你必须明确：先删除外键，再删除表。先创建表，再添加索引。这种显式性带来安全感——你不会遇到"工具自动做了某件事但你不知道"的情况。

但代价是环境依赖。你的本地环境必须连接到目标数据库。网络问题、权限配置、VPN 连接——任何一环出错，迁移就停滞。

MCP：AI 辅助的上下文理解

MCP（Model Context Protocol）改变了迁移的交互方式。

传统 CLI 是你告诉工具"做什么"。MCP 是你描述"想要什么"，AI 推理出具体步骤。

举例：你说"给 users 表添加 email_verified 字段，默认值为 false"。MCP 会：

1. 检查当前 schema
2. 生成对应的 SQL
3. 验证语法
4. 询问是否执行

这个过程是对话式的。你不需要记住 PostgreSQL 和 MySQL 的语法差异。你不需要查文档确认 ALTER TABLE 的正确写法。MCP 理解上下文，适配目标数据库。

但 MCP 不是万能的。它依赖 AI 模型的推理能力。复杂迁移（如大规模数据转换、多表联动）可能需要多轮对话才能准确表达意图。这个过程比直接写 SQL 慢。

参考 debugging-supabase-connections 了解 MCP 如何与 Supabase 集成。

线上 SQL：即时性与风险

直接在 Supabase 的 SQL Editor 中执行迁移，最大优势是即时性。

打开浏览器，写 SQL，点击运行。不需要配置本地环境，不需要安装工具，不需要连接 VPN。变更立即生效。

这种方式适合紧急修复。生产环境出现问题，表结构需要立即调整。写一条 ALTER TABLE 语句，执行，问题解决。

但即时性也是风险。没有版本控制，没有 code review，没有回滚机制。一条错误的 DROP COLUMN 可能删除关键数据。一个忘记的 WHERE 子句可能影响所有记录。

线上 SQL 是双刃剑。它给你最大的灵活性，也要求你承担最大的责任。

选择的权衡

三种方法对应三种场景：

CLI 是日常开发的默认选择。迁移文件进入 Git，团队成员同步 schema，CI 自动部署。这是最安全、最可控的路径。

MCP 适合探索性修改。你不确定最佳 schema 设计，需要快速尝试不同方案。AI 帮你生成 SQL，你验证效果，然后将最终方案转化为迁移文件。

线上 SQL 是应急通道。生产环境问题需要立即修复，没有时间走完整流程。但用完后，必须补充对应的迁移文件，同步到代码库。

没有"最好"的方法。只有在特定场景下，最合适的选择。

迁移的纪律

无论用哪种方法，核心原则不变：

每次变更都要记录。即使是临时修复，也要在事后生成迁移文件。数据库的当前状态必须能从迁移历史中完整复现。

测试先于执行。在测试环境验证迁移，确认无误后再应用到生产。一条未测试的 SQL 就是一次赌博。

小步前进。一次迁移只做一件事。添加字段是一次迁移，修改约束是另一次。这样出问题时容易定位，回滚时影响范围小。

迁移工具在变，方法在变，但纪律不变。数据库是应用的基石。对它的每次改动都值得慎重。