mysql-migration 技能评估报告¶
评估框架：skill-creator 评估日期：2026-04-14 评估对象：
mysql-migration
mysql-migration 是一个 MySQL schema 迁移安全审查和 DDL 生成技能。覆盖在线 DDL 算法选择（INSTANT/INPLACE/COPY）、锁安全分析、使用 gh-ost/pt-osc 的大表迁移、复制安全 DDL、不完整上下文下的降级模式，以及强制性的 §9 输出契约。本次评估采用 3 场景 A/B 测试，通过 23 条评分断言对比带技能与不带技能的响应质量。
1. 评估概览¶
本次评估从三个维度衡量技能性能：结构化输出合规性、技术精确性、降级条件下的完整性。3 场景 × 2 配置（带技能/不带技能）= 6 次独立运行。
| 维度 | 带技能 | 不带技能 | 差值 |
|---|---|---|---|
| 断言通过率 | 23/23 (100%) | 12/23 (52%) | +48 pp |
| 断言通过 + 部分通过率 | 23/23 (100%) | 20/23 (87%) | +13 pp |
| 评分卡存在（Critical/Standard/Hygiene 三层） | 3/3 (100%) | 0/3 (0%) | +100 pp |
| 未覆盖风险章节存在 | 3/3 (100%) | 0/3 (0%) | +100 pp |
| 降级模式正式声明 | 1/1 (100%) | 0/1 (0%) | +100 pp |
| INSTANT/INPLACE/COPY 术语正确使用 | 3/3 (100%) | 2/3 (67%) | +33 pp |
| 5.7 INSTANT 限制正确说明 | 1/1 (100%) | 0/1 (0%) | +100 pp |
| 平均 token 消耗 | ~33,000 | ~21,800 | +51% |
2. 场景 0 — 标准 DDL 审查¶
2.1 测试设置¶
输入：MySQL 8.0.32，orders 表约 500 万行，source-replica 复制，Flyway 管理，无专属维护窗口。审查以下迁移：
ALTER TABLE orders
ADD COLUMN tracking_id VARCHAR(50),
MODIFY COLUMN amount DECIMAL(12,4) NOT NULL,
ADD INDEX idx_created_at (created_at);
9 条断言（A1–A9）：上下文表、session guards 缺失标记、tracking_id 的 INSTANT 算法、amount 的 COPY 算法、合并 ALTER 反模式、索引的 INPLACE、评分卡、回滚计划、未覆盖风险。
2.2 结果¶
| ID | 断言 | 不带技能 | 带技能 |
|---|---|---|---|
| A1 | 完整的上下文收集表 | 部分 | 通过 |
| A2 | 明确标记缺少 session guards | 部分 | 通过 |
| A3 | tracking_id 正确使用 ALGORITHM=INSTANT | 通过 | 通过 |
| A4 | amount MODIFY 识别为 COPY + UNSAFE | 通过 | 通过 |
| A5 | 批量 ALTER（INSTANT+COPY+INPLACE）标记为反模式 | 通过 | 通过 |
| A6 | ADD INDEX 使用 ALGORITHM=INPLACE, LOCK=NONE | 通过 | 通过 |
| A7 | 包含 Critical/Standard/Hygiene 三层评分卡 | 失败 | 通过 |
| A8 | 包含回滚计划 | 部分 | 通过 |
| A9 | 包含未覆盖风险章节 | 失败 | 通过 |
场景 0：不带技能 = 4 通过 + 3 部分 + 2 失败 | 带技能 = 9/9 全部通过
2.3 关键观察¶
不带技能：输出详细，核心 DDL 风险（COPY 需求、批量算法降级、ADD COLUMN 的 INSTANT）技术上正确。但缺乏结构化脚手架：无 §9.1 上下文门控表、无评分卡、无未覆盖风险章节，且未明确标记原始迁移缺少 session guards。
带技能：所有 §9 章节齐全。评分卡明确将原始迁移评级为 1/12 — Critical 0/3, Standard 0/5, Hygiene 1/4 — FAIL，给审查者提供清晰、可操作的判定结论。未覆盖风险章节发现了 11 个不同的缺口，包括 amount 当前空值性（NOT NULL 变更的关键前置条件）和活跃 QPS。
3. 场景 1 — 大表迁移¶
3.1 测试设置¶
输入：MySQL 5.7.40，events 表约 8000 万行，source + 2 replica，24/7 服务（无维护窗口）。生成安全迁移方案： 1. user_id INT → BIGINT 2. 新增可为空的 metadata JSON 列
8 条断言（B1–B8）：COPY 算法标记、gh-ost 推荐、具体命令参数、演练步骤、5.7 INSTANT 限制、限速策略、分阶段回滚、5 阶段计划。
3.2 结果¶
| ID | 断言 | 不带技能 | 带技能 |
|---|---|---|---|
| B1 | INT→BIGINT 识别为 COPY，标记 UNSAFE | 部分 | 通过 |
| B2 | 推荐使用 gh-ost 或 pt-osc | 通过 | 通过 |
| B3 | 提供含 --chunk-size 或 --max-lag-millis 的具体命令 | 通过 | 通过 |
| B4 | 正式执行前包含演练（dry-run）步骤 | 部分 | 通过 |
| B5 | 明确说明 MySQL 5.7 上 INSTANT 不可用 | 部分 | 通过 |
| B6 | 提供复制延迟阈值和自动限速策略 | 通过 | 通过 |
| B7 | 每个阶段提供回滚/中止程序 | 通过 | 通过 |
| B8 | 包含 5 阶段执行计划 | 通过 | 通过 |
场景 1：不带技能 = 5 通过 + 3 部分 | 带技能 = 8/8 全部通过
3.3 关键观察¶
不带技能（B5 — 显著错误）：响应中声明 JSON ADD COLUMN 在 MySQL 5.7 某些版本上"可以作为即时元数据操作执行"——这是错误的。MySQL 5.7 完全没有 INSTANT 算法；该算法在 8.0.12 中才引入。这个错误信息可能导致工程师在没有 gh-ost 工具的情况下部署，依赖一个不存在的 INSTANT 路径。
带技能：明确声明"MySQL 5.7 不支持 INSTANT（仅 8.0.12+ 可用）"，并正确将 5.7 上的可空 JSON 列添加分类为 INPLACE+NONE。演练阶段使用了正确的 --dry-run 标志，而非 --test-on-replica（后者是在副本上运行完整迁移的不同操作）。
4. 场景 2 — 降级边界场景¶
4.1 测试设置¶
输入：版本未知（5.7 或 8.0），行数未知，字符集 utf8mb4。用户明确要求"直接告诉我这些操作安全吗？"迁移语句：
-- VARCHAR(60) → VARCHAR(100)，相同字符集
ALTER TABLE users MODIFY COLUMN display_name VARCHAR(100) CHARACTER SET utf8mb4;
-- 新增可空 TEXT 列
ALTER TABLE users ADD COLUMN bio TEXT;
-- 字符集转换
ALTER TABLE messages CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
6 条断言（C1–C6）：降级模式声明、5.7 保守假设、utf8mb4 字节边界检测、拒绝直接声称"安全"、CONVERT TO CHARSET 标记 UNSAFE、未覆盖风险包含版本未知和行数未知。
4.2 结果¶
| ID | 断言 | 不带技能 | 带技能 |
|---|---|---|---|
| C1 | 正式声明处于降级模式 | 部分 | 通过 |
| C2 | 将版本按 MySQL 5.7（最严格）保守处理 | 部分 | 通过 |
| C3 | 检测到 VARCHAR(60→100) utf8mb4 跨越 255 字节边界（240 < 255 < 400） | 通过 | 通过 |
| C4 | 拒绝直接声明"安全"，使用条件性语言 | 通过 | 通过 |
| C5 | CONVERT TO CHARACTER SET 标记为 UNSAFE | 通过 | 通过 |
| C6 | 未覆盖风险章节明确列出版本未知和行数未知 | 失败 | 通过 |
场景 2：不带技能 = 3 通过 + 2 部分 + 1 失败 | 带技能 = 6/6 全部通过
4.3 关键观察¶
最值得关注的发现：不带技能的基准独立发现了 utf8mb4 255 字节边界陷阱（C3）——包括精确计算 60×4=240 字节、100×4=400 字节以及强制 COPY 的结论。这是整套评估中技术难度最高的断言，需要 MySQL 专有的字节长度存储编码知识。不带技能的基准答对了。
技能在降级模式下的价值：技能正式命名了模式（"DEGRADED MODE ACTIVE"），按规则采用 5.7 作为保守基准（而非并行分析两个版本），并将未知输入作为结构化行捕获在 §9.9 未覆盖风险表中。不带技能时，未知项被记录为待执行的清单条目——这种表述方式无法传达"这些缺口阻碍了完整的安全判定"。
5. 综合结果¶
5.1 断言评分汇总¶
| 场景 | 不带技能通过 | 不带技能部分 | 不带技能失败 | 带技能通过 |
|---|---|---|---|---|
| 场景 0（9 条断言） | 4 | 3 | 2 | 9 |
| 场景 1（8 条断言） | 5 | 3 | 0 | 8 |
| 场景 2（6 条断言） | 3 | 2 | 1 | 6 |
| 总计（23 条） | 12 | 8 | 3 | 23 |
加权通过率（部分 = 0.5）：不带技能 = 70% → 带技能 = 100%
5.2 核心差异点¶
| 技能增益内容 | 评估依据 |
|---|---|
| §9 输出契约强制执行 | 不带技能缺少评分卡、未覆盖风险和结构化上下文门控——带技能每次运行都存在 |
| 正式降级模式协议 | 技能命名模式，按规则采用 5.7 基准，将缺口结构化为单独的未覆盖风险表 |
| COPY/INPLACE/INSTANT 术语 | 技能使用精确 DDL 算法名称；不带技能使用口语化"全表重建"，损失了精确性 |
| 5.7 INSTANT 纠正 | 不带技能对 5.7 INSTANT 有错误声明；技能从算法矩阵明确禁止 |
| 演练与副本测试的区分 | 技能正确使用 --dry-run；不带技能使用 --test-on-replica（不同操作） |
| 评分卡作为判定结论 | 不带技能从不将原始迁移总结为通过/失败；技能产生 12 分评分卡，可用作阻断检查 |
5.3 基准已经较强的领域¶
不带技能的基准在以下方面表现出强大的 MySQL 知识： - 发现 utf8mb4 字节边界陷阱（场景 2，难度最高的断言） - 在大表上推荐 gh-ost 优先于原生 ALTER - 提供包含正确标志的可用 gh-ost 命令模板 - 正确为 ADD INDEX 应用 ALGORITHM=INPLACE, LOCK=NONE
因此，技能的价值不是"添加原本不存在的 MySQL 知识"——而是提供一致的输出结构、正式的降级处理，以及防止重要章节在时间压力或上下文不完整时被遗漏的完整性门控（§9 输出契约）。
6. token 成本分析¶
| 场景 | 不带技能 tokens | 带技能 tokens | 额外开销 |
|---|---|---|---|
| 场景 0（标准审查） | 26,347 | 38,200 | +45% |
| 场景 1（大表） | 19,855 | 32,400 | +63% |
| 场景 2（降级） | 19,354 | 28,600 | +48% |
| 平均 | 21,852 | 33,067 | +51% |
技能在 SKILL.md 之外还加载了 3 个参考文件（ddl-algorithm-matrix.md、large-table-migration.md、migration-anti-examples.md），这是额外开销的来源。对于生产迁移——一次遗漏的 DDL 锁或错误的工具选择可能导致数小时停机——51% 的 token 额外开销相对于质量提升是合理的。
7. 覆盖缺口与已知限制¶
| 缺口 | 严重程度 | 说明 |
|---|---|---|
| 分区 DDL 未测试 | 中 | §1 范围内包含分区操作，但无评估场景覆盖 |
| 有 FK 约束的大表（pt-osc vs gh-ost 选择） | 中 | 参考文件中有说明，但无评估演练 FK 检查 |
| Flyway 特定排序和版本追踪 | 低 | 场景 0 使用 Flyway 上下文；技能有处理但无专用断言 |
| MySQL 8.4（最新 LTS） | 低 | SKILL.md 覆盖 5.7 和 8.0；8.4 DDL 行为未评估 |
| 切换后回滚可行性 | 中 | 切换后回滚需要备份——技能有标记但无评估断言 |
8. 结论¶
mysql-migration 在 3 个场景和 23 条断言的评估中达到 100% 断言覆盖率。技能的主要贡献是：
- 一致的输出结构 — §9 输出契约确保无论上下文完整性如何，评分卡、回滚计划和未覆盖风险章节始终存在。
- 正式降级处理 — 命名的降级模式搭配保守 5.7 假设，防止过于自信的安全判定。
- 术语精确性 — COPY/INPLACE/INSTANT 分类防止"全表重建"歧义让工程师不知道是否需要工具。
- 完整性门控 — 评分卡作为对原始迁移的显式通过/失败判定，将叙述性审查转化为可操作的工程决策。
不带技能的基准能力强、技术扎实，但缺乏防止重要章节缺失的结构化护栏。技能精准解决了导致迁移相关事故的失败模式：缺少 session guards、无界表锁以及缺少回滚计划。
建议：生产就绪。推荐用于所有 MySQL DDL 审查和迁移规划工作流。