技能使用指南

migration（数据库迁移技能）Skill 如何实现可逆迁移？

数据库迁移技能Skill（migration）让 AI 生成 SQL 迁移时默认附带可逆的向下迁移脚本、预迁移清单与风险分级，覆盖加列、删表、重命名、类型变更及百万行大表分批迁移等场景，帮后端开发与 DBA 把“回不回得去”提前想清楚。本文详解安装步骤、用法示例、竞品对比与实战体验，3 分钟看懂如何让每次架构变更安全可回滚。

数据库迁移技能Skillmigration
8 个章节 约 12 分钟阅读 AI 智能生成

数据库迁移技能Skill：让每一次数据库架构变更都自带可回滚的“后悔药”

  • 核心定位：这是一个专为“改表结构”而生的技能，它不只帮你写向上迁移，还强制你写好向下迁移，让变更可撤销。
  • 开箱即用的资产：内置迁移模板（含向上/向下两段事务）与预迁移清单，把“上线前该检查什么”固化成流程而不是靠记忆。
  • 风险前置：把迁移分为安全、风险、危险三档，删表、删列、改类型这类操作会被明确标红。
  • 大表有方案：针对行数超过 100 万的大表，给出“建新结构 → 分批回填 → 加约束 → 切换 → 清理”的五步法。
  • 适合谁用：后端开发、DBA、技术负责人，以及任何需要在生产环境动数据库结构、又不想在凌晨被告警叫醒的人。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

基本信息

项目 内容
技能中文名 数据库迁移技能Skill
技能英文名 migration
技能ID 11836
核心能力 创建带有回滚脚本的可逆数据库迁移，在修改数据库架构时使用

它到底解决什么问题？

改数据库结构这件事，难点往往不在“改”，而在“改错了回不去”。绝大多数线上事故并不是 SQL 写错，而是：脚本跑了、数据没了、没有向下迁移、备份又是三天前的。这个技能的价值主张非常直接——任何一次架构变更，都必须同时交付出“向上”和“向下”两段脚本，并且在上线前把风险想清楚。它把行业里老手才有的肌肉记忆（先测回滚、分批回填、加索引要并发），变成 AI 默认就会执行的产出规范。

“一键安装”的思路与步骤

AI 技能的安装逻辑，本质是给 AI 助手挂载一份“专业作业规范”。安装路径通常如下（具体入口、命令与命名以官方说明为准）：

  1. 确认前提：你的 AI 编程助手或客户端支持技能（Skill）机制；项目里已有（或准备建立）数据库迁移目录；明确目标数据库类型（模板示例使用 PostgreSQL 风格语法，其他数据库需按方言调整）。
  2. 找到技能入口：打开技能市场、插件市场或技能管理面板。
  3. 检索技能：用技能ID 11836 或英文名 migration 搜索，也可按中文名“数据库迁移技能”查找。
  4. 安装并启用：点击安装/启用，确认该技能对当前工作区或会话生效。
  5. 验证是否生效：向助手提一个真实需求，例如“帮我给 orders 表新增一个可为空的 note 字段，并写好回滚”。如果返回结果同时包含向上迁移与向下迁移两段脚本，并附带预迁移清单与风险等级判断，说明技能已生效。
  6. 未生效的排查顺序：技能是否处于启用状态 → 当前会话是否需要重开 → 工作区作用域是否正确 → 是否被其他技能/规则覆盖（以官方说明为准）。

2. 该技能的主要功能和特点

  • 可逆迁移模板：提供规范的迁移脚本骨架，头部注释包含“迁移描述、创建日期、作者”，正文拆成“向上迁移”和“向下迁移”两个事务块，两段都用 BEGIN; ... COMMIT; 包裹，保证原子性。
  • 预迁移清单（上线前的五道关）：向下迁移工作正常、在生产类似数据上测试、性能影响评估、备份计划文档化、部署时间考虑。这五项看起来朴素，但每一项都对应过真实的线上事故。
  • 迁移风险三档分级：
    • 安全迁移：新建表、新增可为空列、并发创建索引、添加不校验的外键；
    • 风险迁移：删表（需验证无引用）、删列（需验证无使用）、重命名列（可能破坏应用）、更改列类型（可能丢数据）；
    • 危险迁移：清空表、删除数据库、移除约束。
  • 大表迁移方法论：面向行数超过 100 万的表，给出“创建新结构 → 分批回填 → 添加约束 → 切换 → 清理旧结构”的五步法，避免一条 ALTER 把表锁死。
  • 回滚策略成文：明确要求“在运行向上迁移之前先测试向下迁移”、文档化手动回滚步骤、确保拥有生产备份、并考虑用功能标志（Feature Flag）承接代码层的配套改动。
  • 和普通工具比强在哪：普通 AI 对话只会给你一段“能跑”的 SQL；这个技能交付的是一份可评审、可回滚、有风险标注的变更方案。普通迁移框架（如版本化管理工具）解决的是“按顺序执行”，它解决的是“写的时候就想好怎么退”。

3. 如何使用该技能？

第 1 步：描述你的变更意图

用自然语言说清楚三件事：改哪张表、改什么、为什么要改。例如：

“给 users 表加一个可为空的 phone 字段，用于短信登录，需要可回滚。”

第 2 步：获取双段脚本

技能会按模板输出向上与向下两段。以上需求对应的典型产出形态如下：

-- 迁移：为 users 表新增 phone 字段
-- 创建日期：[日期]
-- 作者：[姓名]

-- ==================== 向上迁移 ====================
BEGIN;
ALTER TABLE users ADD COLUMN phone VARCHAR(32);
COMMIT;

-- ==================== 向下迁移 ====================
BEGIN;
ALTER TABLE users DROP COLUMN IF EXISTS phone;
COMMIT;

第 3 步：对照预迁移清单逐项确认

重点看两项：向下迁移是否真的能撤销这次变更；这个操作在“和生产数据量级相近”的库上跑过没有。

第 4 步：判断风险等级并决定发布方式

新增可为空列属于安全迁移，通常可直接发布；如果输出提示“更改列类型”或“重命名列”，则属于风险迁移，需要评估应用侧兼容性与数据丢失风险。

第 5 步：大表场景追加分批方案

若表行数超过 100 万，直接 ALTER 可能造成长时间锁表。此时按五步法执行：先建新结构，再分批回填数据，然后补上约束，接着切换读写，最后清理旧结构。

第 6 步：在测试库完整演练一次

顺序建议是“向上 → 向下 → 再向上”，确认向下迁移确实能把结构还原到初始状态，再进生产。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
migration（数据库迁移技能） AI 侧的迁移“作业规范” 可逆模板、预迁移清单、风险三档分级、大表五步法、回滚策略 在 AI 客户端安装启用即可，无需改项目构建链 需要“边写边想回滚”的日常架构变更 优势：把回滚与风险评审前置到写脚本那一刻；不足：不负责版本号管理与执行编排，需搭配迁移工具落地
Flyway 数据库版本化管理工具 版本脚本按序执行、迁移历史表、校验和防篡改 需引入依赖、配置连接、约定命名规范 团队统一管理迁移顺序与发布审计 优势：执行可靠、生态成熟；不足：回滚通常要另写 undo 脚本，规范靠人守
Liquibase 声明式变更管理平台 Changeset、变更日志、支持多数据库方言、回滚标签 需引入依赖与 changelog 结构，学习成本中等 多数据库兼容、需要结构化变更描述 优势：方言抽象好、回滚能力内建；不足：XML/YAML 描述较重，小项目显得繁琐
Alembic 等 ORM 迁移 与代码同仓的迁移框架 自动生成迁移脚本、升降级函数 与 ORM 生态绑定，需按框架约定组织 Python 等 ORM 项目的结构演进 优势：与模型天然同步；不足：自动生成结果需人工复核，跨语言/跨团队不通用
通用 AI 对话直接写 SQL 一次性脚本生成 按描述产出 SQL 零门槛 临时查询、一次性小改动 优势：快；不足：通常不主动给回滚脚本、不做风险分级、不提醒备份与分批，风险全留给使用者

一句话选型建议：执行与版本编排交给专业迁移工具，脚本质量与回滚设计交给这个技能，两者是互补而非替代关系。

5. 该技能的典型应用场景与实际体验情况

场景一：后端开发的日常加字段

角色：业务线后端工程师。痛点是加字段这种“小事”最容易随手写一句 ALTER TABLE 就提 PR，评审时没人追问回滚。使用方式是把需求丢给助手，拿到双段脚本后贴进迁移目录。实际体验：上手几乎零成本，输出结构稳定，头部注释和事务包裹省去了反复对齐规范的时间；需要注意的是删除列时的“验证无使用”仍要自己 grep 代码确认。

场景二：技术负责人的上线评审

角色：Tech Lead / 架构师。痛点是评审时缺少统一的提问框架。使用方式是把待上线的迁移脚本交给技能，让它按三档风险分类并输出预迁移清单核对结果。实际体验：风险分级能有效拦住“顺手删了个没人用的列”这类操作；注意清单是“检查项”而非“结论”，备份是否真的做过仍需人工确认。

场景三：百万行大表的结构调整

角色：DBA / 运维。痛点是直接改结构导致锁表、业务超时。使用方式是明确告知表的数据量级，触发五步法建议。实际体验：五步法本身是业界通行做法，技能的价值在于“每次都提醒你”，避免赶进度时跳过回填分批；注意回填批次大小与限流策略需要结合业务低峰期自行确定。

场景四：故障回滚与演练

角色：值班工程师。痛点是出事时找不到回滚脚本。使用方式是平时就让每次迁移都沉淀向下脚本与手动回滚步骤文档。实际体验：把“回滚”从口头承诺变成仓库里的文件，演练时可执行、可验证；注意部分数据库对 DDL 的事务支持有限，脚本里的事务包裹在不同数据库上的实际效果需实测确认，不能想当然。

6. 该技能能为用户带来的价值

  • 把回滚从“承诺”变成“资产”：每次变更都留下可执行的向下脚本，事故时的恢复时间从“小时级翻备份”压缩到“分钟级执行脚本”。
  • 风险前置，减少返工：三档风险分类让“删列、改类型”这类操作在写的时候就被标注，避免上线前一刻才发现不可逆。
  • 降低新人门槛：迁移脚本的规范性不再依赖个人经验，新人第一次提迁移 PR 就能带上注释头、事务包裹、回滚段和检查清单。
  • 评审效率提升：预迁移清单天然就是一份评审 checklist，把“凭感觉 review”变成“按项确认”。
  • 长期可审计：统一的模板结构让迁移历史更易检索与复盘，也为后续接入版本化迁移工具打下规范基础。

7. 常见问题 FAQ

Q1：这个技能怎么安装？收费吗？

在支持技能机制的 AI 客户端里，通过技能市场或技能管理面板，用技能ID 11836 或英文名 migration 检索后安装启用即可。是否需要付费、有哪些套餐，以官方说明为准；安装入口与具体命令同样以官方文档为准。

Q2：它支持 MySQL、SQL Server 等其他数据库吗？

技能提供的是迁移方法论与模板骨架，示例脚本使用 PostgreSQL 风格语法（如 gen_random_uuid()）。换到其他数据库时，函数、IF EXISTS 支持情况、以及 DDL 是否可包在事务中都需要按方言调整，建议先在测试库验证。

Q3：它和 Flyway、Liquibase 会冲突吗？该选哪个？

不冲突。它们解决的是“按什么顺序执行、执行记录如何留痕”，这个技能解决的是“脚本怎么写才可逆、风险在哪”。实践中常见的组合是：用本技能产出并评审脚本，用版本化工具负责执行与审计。

Q4：适合谁用？前端或非后端同学有必要装吗？

主要面向需要修改数据库结构的后端开发、DBA、数据工程与技术负责人。非后端同学若参与数据相关变更评审，也可以借助它的风险分级快速判断一次变更是否“危险”。

Q5：用了它是不是就万无一失了？

不是。技能给的是规范与检查项，最终是否执行到位仍取决于人：向下迁移要在生产类似数据上实测，备份要真的存在，部署时间要避开业务高峰。它降低的是“想不到”的概率，而不是替代判断。