数据库版本管理需将ddl、dml及权限变更代码化、自动化、版本可控，通过带时间戳的幂等迁移脚本（up/down分离）、flyway/liquibase工具跟踪执行状态，并确保开发、测试、生产三环境迁移链一致，禁止生产库手动执行alter。
数据库版本管理不是给数据库打个标签就完事，核心是让结构变更可追溯、可重复、可回滚。MySQL 项目迁移的关键，在于把 DDL（建表、改字段）、DML（初始化数据、配置项）和权限变更，全部纳入代码化、自动化、版本可控的流程中。
用迁移脚本代替手动执行
每次结构变更（比如加字段、改索引、拆表）都写成独立的 SQL 文件，命名带时间戳和序号，例如：202405101430_add_user_status_v2.sql。文件内容只做一件事：升级（up）或降级（down）。避免“if not exists”式模糊逻辑，确保每次执行行为确定。
- 升级脚本负责新增/修改/填充，必须幂等或明确校验前置状态
- 降级脚本负责安全回退，比如删字段前先备份数据，改类型前确认无数据丢失
- 所有脚本统一放在项目 /db/migrations 目录下，随应用代码一起提交 Git
引入轻量迁移工具（如 Flyway 或 Liquibase）
不依赖人工记录“当前到哪一步”，让工具自动维护 schema_version 表，跟踪已执行脚本、执行时间、校验和。Flyway 更适合 MySQL 纯 SQL 场景，Liquibase 支持 YAML/JSON 描述变更，对跨库兼容性更好。
- Flyway 默认扫描 src/main/resources/db/migration 下的 V*.sql 文件
- 首次运行自动建 flyway_schema_history 表，后续启动时自动比对并执行缺失脚本
- 上线前可在测试库执行 flyway info 查看待执行列表，避免遗漏
开发、测试、生产环境保持迁移链一致
三个环境不能各自为政。开发环境改了表，必须立刻提交迁移脚本；测试环境部署前，先用同一套脚本重放一遍；生产上线时，只执行“本次发布新增”的脚本（靠版本号或 tag 控制），而非全量重跑。
- 禁止在生产库直接执行 ALTER TABLE —— 即使只是加个注释，也得走脚本
- 敏感操作（如 DROP COLUMN、修改主键）需在脚本中加注释说明影响，并经 DBA 审核
- CI 流程中加入 mysql -h test-db -u user 验证语法，或用 Flyway validate 校验 checksum
数据迁移与结构迁移分离处理
大表数据重分布（如分库后迁移用户数据）、历史数据归档、枚举值补全等，不属于结构迁移范畴，应单独写 data/ 目录下的脚本，并标注执行时机（如“需在 v2.1 升级后、服务重启前执行”）。
- 数据脚本也要版本化、幂等化，例如用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE
- 超大数据量迁移建议用程序分批处理，SQL 脚本只做轻量初始化或兜底校验
- 导出初始数据（如系统配置、地区字典）可用 mysqldump --no-create-info --skip-triggers 生成 seed.sql
