迁移MySQL历史数据需先评估分类再选型：按访问频率、业务依赖、外键关联、时间分区打标签；小数据量用逻辑导出，大数据量宜用增量同步或分批迁移，全程保障一致性与低影响。
迁移 MySQL 历史数据不是简单地导出再导入，关键在于分清数据价值、控制影响范围、保障一致性。直接全量 dump 可能导致锁表、服务中断、新旧系统不兼容，尤其在生产环境必须规避。
评估与分类：哪些数据真要迁？
历史数据往往混杂冷热数据，盲目迁移既浪费资源又增加风险。建议按以下维度打标签：
- 访问频率：半年内无查询的日志类、操作记录可归档或只保留元数据
- 业务强依赖：用户档案、订单主表、合同信息等必须完整迁移并校验
- 外键/关联依赖：如订单表依赖用户表和商品表，需确认依赖链是否同步迁移
- 时间分区特征：若原表按月分表（如 order_202201），优先按分区粒度迁移，避免单次处理过大
迁移方式选型：根据场景定策略
没有“万能方案”，需结合数据量、停机窗口、目标库结构判断：
- 小数据量（：mysqldump + --single-transaction + --skip-triggers，导入前禁用外键检查
- 大数据量 + 需在线迁移：用 pt-online-schema-change 或 gh-ost 搭配逻辑复制，逐块拷贝+增量同步，最后切流
- 跨版本/跨引擎（如 MyISAM → InnoDB）：先用 mysqldump 导出 SQL，人工清理不兼容语法（如 ENGINE=MyISAM 改为 ENGINE=InnoDB），再导入
- 仅迁移部分字段或脱敏后迁移：用 SELECT INTO OUTFILE + LOAD DATA INFILE，配合 WHERE 和 CONCAT/REPLACE 脱敏敏感字段
一致性保障：不能只靠“跑完就完事”
迁移后必须验证，否则上线即故障：
- 行数比对：源库 SELECT COUNT(*) 与目标库比对，注意事务隔离级别影响（建议 RC 下执行）
- 关键字段抽样校验：如取 ID % 1000 = 1 的 100 条记录，比对主键、更新时间、金额等核心字段
- 逻辑一致性检查：例如“订单总金额 = 明细行 sum(单价×数量)”，写脚本批量验证
- 索引与约束重建：目标库导入后手动执行 ALTER TABLE ... ADD INDEX / ADD CONSTRAINT，避免 dump 时跳过
后续处理：迁完不等于结束
迁移只是起点，还需收尾动作防止隐患：
- 旧库数据冻结：将原表改名（如 order → order_archived_2024），禁止写入，保留只读备查
- 归档策略落地：对真正冷数据，导出为压缩 SQL 或 Parquet 文件，存至对象存储，删库表释放空间
- 应用层适配确认：检查连接串、分库分表路由规则、ORM 映射是否指向新库；监控慢查日志，确认索引生效
- 回滚预案准备：保留旧库快照或延迟从库，确保可在 15 分钟内切回，且有明确的回滚 SQL 清单
不复杂但容易忽略。重点不在工具多强大，而在每一步是否留痕、可验证、可逆。
