메뉴
当用户要求将 MySQL 或 Percona Server 补丁从一个版本移植到另一个版本，并要求实际完成 patch 分析、版本差异比对、代码适配、编译、安装、启动验证、功能验证、patch 生成或提交时使用。适用于多版本 MySQL 内核补丁适配、兼容性修复、MTR 或 sysbench 验证，以及将补丁移植过程标准化为低人工参与流水线。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/kunpengcompute/skills --skill mysql-patch-multi-version-adaptation명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | mysql-patch-multi-version-adaptation |
| description | 当用户要求将 MySQL 或 Percona Server 补丁从一个版本移植到另一个版本，并要求实际完成 patch 分析、版本差异比对、代码适配、编译、安装、启动验证、功能验证、patch 生成或提交时使用。适用于多版本 MySQL 内核补丁适配、兼容性修复、MTR 或 sysbench 验证，以及将补丁移植过程标准化为低人工参与流水线。 |
用于 MySQL / Percona Server 补丁跨版本移植。目标不是只做静态分析，而是尽量完成：
8.0.x 的优化补丁移植到另一个 8.0.y[阶段] [分析] [修改] [问题] [解决] [验证]至少确认以下信息：
如果用户没有给全，先从本地仓库和历史命令补齐，不要立刻停下提问。
如果用户只说“把某个能力移植到目标版本”，而仓库多个分支都存在相近 patch，必须先做参考 patch 选择。
默认先查看 boostkit/mysql 代码仓各分支中的 boostdb-patches/，优先从本地对应镜像仓库读取分支和 patch；如果本地镜像缺失，再看用户提供的源码树。
选择规则按优先级从高到低：
具体解释：
8.0.36 这种目标版本，通常优先参考 8.0.43 一类近版本，而不是 8.0.25。对于 plan cache 这类功能，8.0.36 目标版本更适合参考 MySQL-Percona-Server-8.0.43-34 的 patch，而不是 MySQL-8.0.25。原因是：
8.0.25 分支里根本没有同能力 patch8.0.43-34 与 8.0.36 生命周期、optimizer、prepared statement 结构更接近8.0.43-34 patch 自带更完整的测试和修复历史做完选择后，必须在进度输出里明确说明：
参考规则见：
references/reference-patch-selection.md辅助脚本见：
scripts/select_reference_patch.sh先回答四个问题：
如果 patch 很大，先用命令抽取修改面：
git apply --statgit apply --summaryrgsed -n模块归类优先按以下维度整理：
对 patch 修改过的文件逐个比对目标版本：
冲突原因必须归类，不要只说“apply 失败”：
详细检查清单见：
references/checklists.md先做非破坏性检查：
git apply --check如果大部分 hunk 可用，再在可接受的工作树上做：
git apply --reject --whitespace=nowarn要求：
.rej 文件辅助脚本见：
scripts/mysql_patch_adapt_snapshot.sh人工修复按以下顺序处理：
常见原则：
必须真实执行用户给定编译命令。不要自己换一套构建系统，除非原命令不可用且已证明阻塞。
遇到编译错误时：
至少验证：
mysqld --versionmysqladmin ping如果 patch 与 prepared statement / optimizer / range / filesort / tmp table 有关，必须优先设计针对性 SQL。
如果用户给过故障复现命令，例如 sysbench，要尽量复现同路径验证。
生成的新 patch 要满足：
优先用：
git format-patch如果用户要求提交到远程仓库：
提交前还必须检查“本次改动边界”：
git add <file> 精确暂存；不要把无关改动一起打包进一次提交提交信息必须专业化，不允许使用临时标题，例如：
fixwipport patchupdate默认提交标题格式：
[optimization] ...[bugfix] ...[compatibility] ...[refactor] ...[test] ...选择规则：
[optimization][compatibility][bugfix][refactor][test]默认提交正文格式：
推荐风格示例：
[optimization] Accelerate UTF-8/UTF-8MB4 charset handling on AArch64 with NEON/SVE[compatibility] Adapt plan cache patch to MySQL 8.0.30 lifecycle and PSI interfaces[bugfix] Fix odd-length destination handling in utf8mb4 strxfrm path推荐正文写法示例：
Add AArch64 SIMD implementations for ...Update strings/CMakeLists.txt to probe ...Wire optimized paths into ... while preserving generic fallbacksExtend gunit and mysql-test coverage for ...如果用户指定“参考某个 commit 的提交信息风格”，必须先读取该 commit，再复用它的结构和措辞粒度，不要只模仿标题前缀。
如果需要 amend 或重写提交信息，必须保持代码内容边界不变；只修改提交元数据，不顺手混入额外源码调整。
每次适配结束后，都要沉淀一条案例记录，最少包含：
建议记录到 skill 目录下的案例数据文件：
references/adaptation-cases.jsonl新增案例时，优先追加，不要覆盖历史。
每完成一批适配后，要从案例中反推规则库更新：
如果同类任务连续出现失败或高人工修复占比，必须更新：
references/reference-patch-selection.mdreferences/checklists.mdreferences/case-*.md闭环说明见：
references/continuous-improvement.md记录脚本见：
scripts/record_adaptation_case.py默认用下面结构持续汇报：
[阶段]
正在做什么
[分析]
发现了什么
[修改]
改了哪些文件
[问题]
遇到了什么错误
[解决]
如何修复
[验证]
验证结果
最终总结至少覆盖：
调用本 skill 时，优先采用三层提示结构：
模板见：
references/prompt-template.mdreferences/reference-patch-selection.md本 skill 内置了一份实际案例：
references/case-plan-cache-8.0.43-to-8.0.36.md当用户做的是 MySQL 8.0.x 之间的 patch 迁移，尤其是 optimizer / prepared statement / plan cache 相关 patch，优先参考这份案例。
只有同时满足以下条件，才能称为“移植完成”：
mysqld 成功启动如果其中任意一项未完成，结论必须写成“部分完成”，并明确剩余阻塞。