技能介绍

数据库变更的「黑箱」困境

直接在 MySQL 实例上执行 ALTER TABLE 时，你面临三个核心问题：变更脚本散落在聊天记录或工单里，无法版本化追踪；执行前看不到完整影响面，只能在上线后发现锁表或数据回填问题；多人协作时，谁改了什么、为什么改，往往靠口头同步。这些盲区在高并发、多环境部署时尤其危险——一次忘记加索引的查询优化，可能让线上服务在流量高峰时雪崩。

把架构变更变成可审查的 SQL

这个技能的核心思路是：将线上 schema 拉取为本地文件，用 Git 的方式管理变更，在推送前完成差异审查。具体工作流程：

拉取线上结构：通过 skeema pull 将目标 MySQL/MariaDB 实例的表结构同步到本地文件系统，生成 .sql 文件表示当前状态
生成差异对比：修改本地 .sql 文件或使用 skeema diff 命令，技能会生成标准化的 ALTER STATEMENT，明确展示将要执行的变更
本地审查：在推送前，通过 skeema diff 的输出审查具体影响——是否锁表、是否涉及大表回填、是否有依赖关系冲突
推送变更：审查通过后，使用 skeema push 将变更应用到线上，支持 dry-run 预览

关键优势在于：所有变更都变成可版本化的 .sql 文件，配合 Git 提交历史，谁改了什么一目了然；skeema diff 在推送前生成完整变更脚本，避免上线后发现意外影响。

适用边界与注意点

适用场景：需要管理多个 MySQL 实例 schema 一致性的团队；希望将 DDL 变更纳入代码审查流程的团队；需要在上线前评估变更影响的运维场景。

前提条件：需要已安装 Skeema CLI；需要对目标 MySQL/MariaDB 实例有 schema 读取权限；需要有本地文件系统或 Git 仓库存储 schema 文件。

重要限制：技能关注的是 schema 结构变更（DDL），不处理数据迁移（DML）；对于大表变更，即使使用了 skeema，仍需评估锁表策略（如 ALGORITHM=INPLACE 或 pt-osc）；多个实例间的 schema 一致性需要额外工具（如 skeema diff 的跨实例对比功能）。

不要用它替代完整的数据库迁移工具（如 Flyway 或 Liquibase），它的定位是轻量级的 schema 管理 + 审查流程，适合作为现有发布流程的补充。