关系型数据库迁移与升级：低风险变更的工程流程

数据库迁移和升级是高风险操作。版本升级、云数据库迁移、机房迁移、字符集调整、表结构拆分、分库分表改造，都可能影响业务正确性和可用性。成功的迁移不是把数据复制过去，而是在切换后业务仍然正确、性能可控、可回滚。

低风险迁移的关键是拆小步骤、持续校验、灰度切换。

迁移前评估

先明确迁移目标：

• 降低成本。
• 提升性能。
• 版本生命周期要求。
• 云上托管。
• 容量扩展。
• 架构演进。

然后评估风险：

• 数据量和增长速度。
• 停机窗口。
• 兼容 SQL。
• 存储过程、触发器、函数。
• 字符集和排序规则。
• 时区。
• 隔离级别差异。
• 驱动和连接池兼容性。

MySQL 到 PostgreSQL 不是简单数据搬迁，SQL 方言、类型和事务行为都可能不同。

Schema 变更

大表 DDL 是常见风险。加字段、建索引、改字段类型都可能造成锁、复制延迟和 IO 抖动。

建议：

• 使用在线 DDL 工具。
• 在低峰执行。
• 控制批量大小。
• 监控复制延迟。
• 准备回滚。
• 先在同规模测试环境验证。

对应用兼容性，遵循 expand-contract 模式：先增加兼容字段和代码，再切流量，最后删除旧字段。

数据同步

大迁移通常需要全量加增量：

1. 全量导出导入历史数据。
2. 增量同步 binlog/WAL。
3. 持续校验。
4. 切换写入。
5. 保留回滚窗口。

全量导入期间源库仍在写入，因此必须有增量同步补齐变化。

双写与校验

部分迁移会采用双写，让应用同时写旧库和新库。双写要处理失败场景：旧库成功新库失败、旧库失败新库成功、网络超时结果未知。

如果可以，优先用数据库日志同步减少应用双写复杂度。必须双写时，要设计重试、幂等和补偿。

数据校验包括：

• 行数校验。
• 主键范围校验。
• checksum。
• 核心字段抽样。
• 业务查询对比。

不要只看总行数，总行数相同也可能数据内容不同。

灰度切换

切换不是一次性把所有流量打过去。建议：

• 先只读灰度。
• 再小比例写入。
• 按服务或租户切换。
• 监控错误率、延迟、连接数、复制延迟。
• 保留快速回退入口。

切换期间要冻结高风险 DDL 和批处理任务，避免变量过多。

回滚策略

迁移必须提前定义回滚条件和回滚步骤。常见触发条件：

• 核心接口错误率上升。
• 数据校验失败。
• 写入延迟超阈值。
• 新库复制中断。
• 应用兼容问题。

回滚难点在于切换后新库产生的新数据如何回灌旧库。因此回滚窗口越长，成本越高。切换后要尽快完成确认，避免长期双向同步。

升级验证

版本升级要验证：

• SQL 执行计划变化。
• 默认参数变化。
• 字符集和排序行为。
• 驱动兼容性。
• 复制协议。
• 备份恢复工具。
• 监控告警。

数据库新版本可能让某些查询变快，也可能因为优化器变化让旧查询变慢。升级前要回放核心 SQL。

总结

关系型数据库迁移和升级的核心不是速度，而是确定性。全量加增量、持续校验、灰度切换、明确回滚，是降低风险的关键。数据库变更要像发布核心业务一样严肃对待，因为它一旦出错，影响的是系统事实本身。