技能使用指南

sql-migration-review（数据库迁移脚本评审）Skill 是什么？如何下载？

数据库迁移脚本评审Skill 逐条检查锁表风险、执行时长、回填方案、索引策略与回滚路径，针对 MySQL 与 PostgreSQL 给出可执行改写建议，输出结论、执行计划、回滚方案与监控阈值的结构化报告。本文详解安装步骤、使用方法、竞品对比与典型场景，帮你把 DDL 审到能在生产高峰安全执行，立即了解并启用以提升上线效率。

数据库迁移脚本评审Skillsql-migration-review
8 个章节 约 14 分钟阅读 AI 智能生成

数据库迁移脚本评审Skill：把 DDL 审到能在生产高峰安全执行

  • 定位清晰：这是一个专门针对数据库迁移脚本（DDL、回填、索引变更）的评审技能，目标不是“测试库能跑通”，而是“生产高峰能安全执行”。
  • 逐条拆解：把脚本拆成独立语句，逐条标注语句类型、锁类型、预计耗时与风险等级，再给出改写建议。
  • 覆盖多种数据库：针对 MySQL 与 PostgreSQL 的版本差异分别判断锁行为，避免照搬经验，例如 MySQL 8.0 加列的 INSTANT 行为，以及 PostgreSQL 加约束需 NOT VALID。
  • 自带方法论：内置分批回填四原则、先加后删六步兼容流程、回滚与演练要求，以及一份可直接照着勾的检查清单。
  • 可交付产物：输出结论、逐条评审表、执行计划、回滚方案、监控阈值五段式报告，可直接贴进上线评审会材料。

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

基本信息

项目 内容
技能中文名 数据库迁移脚本评审Skill
技能英文名 sql-migration-review
技能ID 2119807584444252161
核心能力 迁移脚本逐条评审、锁表风险与时长评估、回填方案设计、索引策略、回滚路径、数据兼容性检查
支持数据库 MySQL、PostgreSQL

它解决什么问题

数据库迁移是研发流程里“低频但高危”的动作。一次千万级表的 ALTER TABLE、一条覆盖全表的 UPDATE 回填、一个没先清理重复数据的唯一索引，都可能在业务高峰演变成锁表、主从延迟飙升甚至线上不可用。传统做法依赖资深 DBA 的个人经验，评审靠“看一眼觉得没问题”，缺少结构化清单；而通用 AI 助手虽然能回答 SQL 问题，但往往给出“语法正确、生产危险”的答案。

这个技能把“生产级 DDL 评审”的经验固化成一套工作流：语句分类 → 锁与时长评估 → 回填设计 → 兼容性 → 回滚与演练，最后输出一份结构化评审报告。

一键安装 AI 技能提升开发效率的思路

AI 技能（Skill）本质上是给 AI 助手挂载的一份“专业能力包”，安装后助手在处理相关任务时会自动加载对应的规则、检查清单与输出模板，无需每次重复写长篇提示词。

安装步骤（通用流程，具体命令、入口与是否收费以官方说明为准）：

  1. 确认前提：你的 AI 助手或客户端需要支持技能（Skill）机制，并能读取技能包说明文件；若团队使用自建平台，还需确认已开启技能市场或本地技能目录能力（以官方说明为准）。
  2. 找到技能：在技能市场或技能库中，用技能名称「数据库迁移脚本评审」或技能ID「2119807584444252161」检索定位，避免同名技能混淆。
  3. 一键安装/启用：按平台提供的安装入口完成添加，通常为点击「安装」或在对话中触发技能加载；本地部署场景一般是把技能目录放入指定路径（以官方说明为准）。
  4. 验证是否生效：发起一次小规模测试，例如粘贴一条 ALTER TABLE 语句并追问“这条语句在千万级表上有什么锁风险”，观察回复是否按“语句分类—锁评估—回填/回滚建议”的结构输出。若只是泛泛而谈语法，说明技能未加载成功。

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

  • 语句分类拆解：把脚本拆成元数据变更、表重建、索引变更、数据回填、约束变更五类，逐条标注风险点，避免把整段脚本当成一个整体模糊判断。
  • 锁行为与耗时评估：对照内置的锁行为参考（references/lock-matrix.md），结合目标数据库版本判断语句是即时完成、仅改元数据，还是会锁表或重建拷贝；并给出“行数 × 单行成本 ÷ 磁盘吞吐”的量级估算，明确说明这是数量级而非精确值。
  • 版本差异识别：区分 MySQL 8.0 加列的 INSTANT 行为与改列顺序、改字符集仍需重建表；区分 PostgreSQL 11+ 加带默认值列不重写表、加约束需 NOT VALID 再验证。
  • 回填方案强制约束：回填必须满足分批（按主键区间每批 1000～5000 行并休眠）、幂等（用 WHERE new_col IS NULL 收口）、可观测（每批输出影响行数与耗时）、可暂停（开关或参数控制）四项，明确禁止单条 UPDATE 覆盖全表。
  • 兼容性推进路线：提供“先加后删”六步法：加新列/新表 → 应用双写 → 回填历史数据 → 校验一致性 → 切换读路径 → 观察一个发布周期后删旧列，每步都可独立回滚。
  • 回滚强制成对：要求 DDL 回滚脚本与正向脚本成对提交；对删列、改类型这类不可逆操作，要求备份表或逻辑导出，并建议在预发环境用生产量级数据演练。
  • 可勾选的检查清单：给出十条检查项，覆盖锁类型标注、分批与暂停、默认值安全、索引限速、先建后验、幂等回填、回滚备份、主从延迟熔断、发布顺序、字符集重建成本。
  • 反模式识别：主动指出高峰对千万级表 ALTER、长事务回填、先删列再改应用、唯一索引不先清重、只测空库不测存量等典型错误。
  • 结构化输出模板：固定输出「结论 / 逐条评审表 / 执行计划 / 回滚方案 / 监控」五段，结论直接给出“可在低峰执行 / 需改造后执行 / 禁止直接执行”三档判定。

和普通工具比强在哪：普通 SQL 格式化或语法检查工具只判断语句是否合法；在线 DDL 工具（如 gh-ost、pt-online-schema-change）解决的是“怎么执行”；而这个技能解决的是“该不该这样执行、执行多久、出错怎么办、怎么回滚”，属于上线前的决策环节。

3. 如何使用该技能？

第 1 步：准备四类输入信息

信息越完整，评审越贴近真实。建议按以下结构提供：

  1. 迁移脚本全文 + 目标数据库版本（例如 MySQL 8.0.32 或 PostgreSQL 14）。
  2. 表的行数、日均增长量、读写 QPS、可容忍的主从延迟。
  3. 发布窗口与是否允许停写。
  4. 应用侧是否与迁移同时发布。

特别注意：行数未知时，该技能会按“大表”处理，因为乐观假设的代价是一次生产事故。

第 2 步：发起评审

用自然语言描述场景并粘贴脚本，例如：

帮我评审这份上线迁移脚本，目标是 MySQL 8.0，订单表约 3000 万行，日均增长 50 万，写入 QPS 约 2000，主从延迟容忍 3 秒，发布窗口为凌晨低峰，应用与迁移同时发布。

ALTER TABLE t_order ADD COLUMN channel_code VARCHAR(16) DEFAULT NULL;
UPDATE t_order SET channel_code = 'legacy' WHERE channel_code IS NULL;
CREATE UNIQUE INDEX idx_order_no ON t_order(order_no);

第 3 步：阅读输出报告

输出会按模板组织，重点看四块：

  • 结论：三档判定，直接决定能不能上。
  • 逐条评审表：每条语句的类型、锁、预计耗时、风险、建议。
  • 执行计划：预检查、分批回填、切换步骤的顺序。
  • 回滚方案与监控：主从延迟超过多少秒暂停、锁等待超过多少秒告警。

第 4 步：按建议改造并二次评审

把改写后的脚本再次提交评审，确认“禁止直接执行”的条目已消化，同时确认新增列可空或有安全默认值、旧版本应用在新结构上仍能正常运行。

第 5 步：预发演练后上线

在预发环境用生产量级数据演练一次，记录实际耗时，用真实数据校正估算值，再按执行计划分批推进。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
数据库迁移脚本评审Skill（sql-migration-review） 上线前 DDL 评审与零停机方案设计 语句分类、锁与时长评估、回填设计、兼容性路线、回滚与演练、检查清单、结构化报告 需在支持 Skill 机制的 AI 助手中安装启用；无需数据库连接权限，粘贴脚本即可 上线前评审、大表改造、分库分表迁移、多环境发布 优势：方法论完整、输出可直接进评审会、覆盖 MySQL 与 PostgreSQL 版本差异；不足：耗时为量级估算，最终仍需预发演练校正
资深 DBA 人工评审 人工把关，经验驱动 结合历史事故经验判断锁与风险 依赖人力排期与个人水平，高峰期资源紧张 核心交易库、超大规模变更 优势：判断最贴近实际环境；不足：经验难沉淀、评审标准不统一、重复性劳动多
gh-ost / pt-online-schema-change 等在线 DDL 工具 执行层面的在线变更工具 通过影子表或触发器实现低阻塞表结构变更 需要部署、权限与运维配置，对表结构有前提限制 已经确认可行的大表 DDL 执行 优势：真正降低锁影响；不足：只解决“怎么改”，不判断“该不该改”，回填与回滚方案仍需人工设计
通用 AI 助手直接对话 通用问答 可回答 SQL 语法与优化问题 门槛最低 快速查语法、写初稿 优势：随手可用；不足：缺少固定检查清单与输出模板，容易给出“语法正确但生产危险”的结论，评审口径不稳定

从对比可以看出：在线 DDL 工具解决执行，人工 DBA 解决判断但不可规模化，通用 AI 解决速度但不解决严谨性。这个技能的生态位是“把判断标准化、把报告模板化”。

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

场景一：电商订单表新增字段

  • 角色与痛点：后端研发需要给 3000 万行的订单表加一个渠道来源字段，测试库秒过，但没人能确认生产要锁多久。
  • 使用方式：提供脚本、行数、QPS 与发布窗口，让技能逐条评估加列与回填语句。
  • 实际体验：技能会区分“加可空列”与“改列顺序、改字符集”的不同锁行为，并把单条全表 UPDATE 直接判为高风险，要求改成按主键区间分批。上手难度低，但输入信息越真实，结论越可参考。

场景二：大表加唯一索引上线

  • 角色与痛点：SRE 要在用户表上建唯一索引，但存量数据存在重复，担心迁移中途失败回滚。
  • 使用方式：提交建索引语句与数据现状描述，要求给出索引创建与数据清理顺序。
  • 实际体验：输出会指出“加唯一索引不先清理重复数据”属于反模式，并建议先清理再建，同时给出低峰执行或并发建索引的替代路径，以及主从延迟熔断阈值建议。

场景三：分库分表与字段拆分迁移

  • 角色与痛点：架构师推进分库分表，字段需要在多张表间拆分迁移，担心应用与数据库切换之间存在“读不到数据”的中间态。
  • 使用方式：让技能按“先加后删”六步法排出阶段计划。
  • 实际体验：报告会把双写、回填、一致性校验、读路径切换、观察期拆成独立可回滚步骤，并强制要求回滚脚本成对提交。删列类不可逆操作会被要求先备份。

场景四：多环境发布的回滚预案评审

  • 角色与痛点：发布负责人需要在评审会上拿出可执行的回滚方案，而不是一句“出问题就回滚”。
  • 使用方式：提交正向脚本与回滚脚本，请技能检查两者是否成对、是否覆盖不可逆操作。
  • 实际体验：输出可直接作为评审材料，监控段落给出“主从延迟超过 X 秒暂停、锁等待超过 Y 秒告警”的具体格式，便于填入实际阈值。

综合体验小结：上手难度低，核心门槛在于“愿不愿意把真实表规模说清楚”；效果上，最大的价值是把隐性经验变成显性清单；注意事项是耗时为数量级估算，必须靠预发演练校正，且技能不替代真实环境的监控与灰度。

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

  • 把风险前置：在写代码阶段就把锁表、长事务、不可逆回滚等问题暴露出来，避免把事故成本留到上线当晚。
  • 降低经验门槛：中小团队不一定有全职 DBA，这份技能把资深评审的关注点固化成十条检查清单和五段式报告，让普通研发也能做出接近专业水准的评审。
  • 缩短评审往返：过去“提脚本—等排期—被打回—改—再等”的循环，可以在提交前先自查一轮，评审会上的争论从“我觉得有风险”变成“表格里这条耗时怎么降”。
  • 统一团队口径：所有迁移都按同一套模板输出结论、执行计划、回滚方案与监控阈值，历史评审记录可复用、可检索、可沉淀为团队规范。
  • 长期价值：反模式清单会持续纠偏团队习惯，例如不再写覆盖全表的 UPDATE、不再先删旧列再改应用；这些习惯一旦形成，收益会体现在每一次变更中，而非单次迁移。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要连接数据库吗？

A：在支持技能机制的 AI 助手中，用名称「数据库迁移脚本评审」或技能ID「2119807584444252161」检索并启用即可，具体入口、命令与权限要求以官方说明为准。使用时不要求直连数据库，只需把脚本与表规模、QPS 等信息以文本形式提供。

Q2：收费吗？

A：技能本身的收费方式取决于所在平台的计费规则，请以官方说明为准。技能内容本身以脚本评审与方法论输出为主，不消耗额外数据库资源。

Q3：适合谁用？只适合 DBA 吗？

A：最适合三类人：需要提交迁移脚本的后端研发、负责上线把关的 DBA 或 SRE、推进大表改造与分库分表的架构师。即使团队没有专职 DBA，也可以用它完成提交前的第一轮自查。

Q4：它给出的耗时估算准吗？

A：技能明确说明耗时为“行数 × 单行成本 ÷ 磁盘吞吐”的数量级估算，不是精确值。正确用法是用它判断“是秒级、分钟级还是小时级”，再在预发环境用生产量级数据演练校正。

Q5：和 gh-ost、pt-online-schema-change 这类工具是什么关系？

A：两者互补。在线 DDL 工具解决“怎么低阻塞地执行”，这个技能解决“该不该这样执行、回填与回滚怎么做、发布顺序怎么排”。通常先用技能评审并确定改造方案，再选择在线工具落地执行。