MySQL 结构变更怎么管：从裸 SQL 到 Git 化

早期我做表结构变更，基本是连上生产库直接敲一条 ALTER，改完就忘了。直到有一次本地和线上结构对不上、数据追平出了乱子，我才下决心把数据库变更也纳入工程化管理。

一、每一次变更都写成脚本

现在任何加表、加字段、建索引，都先写成一个带注释的 SQL 脚本，按日期和用途命名，例如：

-- 2026-11-12 增加分享令牌表
CREATE TABLE issue_shares (
  id          BIGINT PRIMARY KEY AUTO_INCREMENT,
  token       VARCHAR(64) NOT NULL,
  issue_id    BIGINT NOT NULL,
  expire_at   DATETIME NOT NULL,
  INDEX idx_token (token)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

脚本即文档：半年后回头看，也知道那天到底动了什么。

二、变更前先备份，再动手

这是铁律。任何结构性操作之前，先 mysqldump 整库备份一次，命名带上时间戳。真改坏了，退回去就是一条命令的事。我为此还专门保留了一份“改前备份”目录。

教训：曾经发生过“只把文件落到运行目录、没真正入库”的事故。现在改完必做内容级核对——确认运行态和入库版本逐字节一致，避免“以为上了、其实没上”。

三、用 Git 管理变更，而不是靠记忆

这些 SQL 脚本和后端代码一起进版本库，分 develop（日常）和 main（正式）两个分支。谁、什么时候、为什么改，提交记录一清二楚。正式部署前必须先让客户确认，再合并到 main。

四、同步纪律：本地不是线上

本地工程目录不是 git 工作区，推送服务器要走固定脚本。最坑的一次是：本地还是旧版，一推送把线上的新版本“顶”了回去。所以推送前必须先做内容比对，确认本地确实是最新的再动。

五、大表变更要温柔

几万行以上的表直接 ALTER 会锁表。能用 ALGORITHM=INPLACE 的就用，加索引尽量在线做；实在避免不了的长操作，挑低峰期、先在小表验证语法。

把数据库当代码管之后，最大的收获是“睡得着觉”。下一篇聊聊性能——结构对了，还得跑得快。