迁移前的准备工作：数据审计与系统评估
数据迁移最怕什么？最怕迁移完了才发现数据对不上。
我见过太多团队，上来就写脚本、搞同步，等到上线一查，发现源库有大量空字段、重复主键，甚至编码都不一致。结果呢？回滚要花双倍时间，老板还要追责。
所以，迁移前的准备工作，说白了就是两件事：把你家底摸清楚（数据审计），把新家量明白（系统评估）。这两步没走完，别碰代码。
数据审计：给源数据做一次全面体检
数据审计不是随便查几个字段就完事了。我个人习惯把它分成三个层面：
- 数据质量检查 — 字段完整性、格式一致性、重复记录
- 数据约束检查 — 主键、外键、唯一索引、非空约束
- 数据依赖检查 — 表之间的关联关系、触发器、存储过程引用
我给一个SQL脚本示例，用来快速扫描源库的数据质量：
-- 检查空值比率
SELECT
table_name,
column_name,
ROUND(100.0 * COUNT(*) FILTER (WHERE column_value IS NULL) / COUNT(*), 2) AS null_percent
FROM information_schema.columns c
LEFT JOIN target_table t ON ...
GROUP BY table_name, column_name
HAVING null_percent > 5;
为什么特别关注空值比率？我在项目中遇到过这样一个坑：某个业务系统的「用户邮箱」字段，理论上应该是必填项，但实际有 30% 是空的。迁移过去之后，新系统的消息推送模块全崩了。你想想看，如果提前审计出来，至少能提前处理。
| 审计维度 | 检查项 | 常见问题 |
|---|---|---|
| 完整性 | 必填字段空值率、主键缺失 | 空值导致下游 ETL 报错 |
| 一致性 | 日期格式、枚举值范围、编码方式 | GBK 编码迁移为 UTF-8 后乱码 |
| 准确性 | 数值越界、金额精度截断 | Decimal(10,2) 与原库精度不匹配 |
| 时效性 | 历史数据过期、失效软删除未标记 | 迁移大量已删除数据浪费空间 |
源系统评估：摸清老系统的脾气
源系统的评估，本质上是在回答一个问题：它到底能扛多久？
迁移期间，源系统还要对外提供服务。如果它本身性能就很差，你还去做全量导出，那其他业务就遭殃了。
- 数据量评估：总行数、数据存储大小（GB/TB 级）、增量每日增长量
- 读写负载评估：QPS、写入并发、有没有长时间锁表
- 表结构复杂度：大宽表、自引用表、分区表、分库分表
我记得有一次，客户说「数据量不大，也就 2TB」。我一查，发现他们用的是 MySQL MyISAM 引擎，导出期间会锁全表。2TB 的表锁上几个小时，业务就停了。这就是典型的源系统评估不足。
max_allowed_packet 参数，导致大字段导出时直接报错断开。建议先执行 SHOW VARIABLES LIKE '%max%'; 记录所有限制参数。
目标系统评估：新家的承载力测算
目标系统评估，我通常关注三点：容量规划、兼容性、性能基准。
容量规划不是简单看剩余磁盘空间，要考虑未来 6-12 个月的增长。我给一个经验公式：
所需存储 = 源数据大小 * 1.5（索引和冗余） + 日志空间（建议 100GB）+ 回滚快照空间（至少等于源数据大小）兼容性则是比较隐蔽的坑。比如 MySQL 迁移到 PostgreSQL，字符串排序规则不同、自增主键实现不同，这些都会影响应用层。我建议提前建一个小规模测试环境，做一次端到端的数据校验。
| 评估要素 | 源系统（来源） | 目标系统（去向） |
|---|---|---|
| 数据库版本 | MySQL 5.7 | MySQL 8.0 / TiDB |
| 存储引擎 | MyISAM + InnoDB | InnoDB 统一 |
| 编码 | gbk, utf8mb3 | utf8mb4 |
| 最大连接数 | max_connections=500 | max_connections=2000 |
| 数据量峰值 | 20w QPS（读） | 50w QPS 估算 |
1. 源数据有哪些问题必须迁移前修复。
2. 源系统的负载窗口期在哪里，能接受的迁移耗时。
3. 目标系统在容量和性能上是否满足未来需求。
嗯，讲了这么多，其实核心就一句话：不了解老系统和新系统的边界，迁移就是对业务耍流氓。 我每次做迁移，这些工作至少花掉整个项目 30% 的时间。但恰恰是这部分时间，帮我避开了后面 70% 的坑。