数据量大、业务又不能停，这是很多团队上云时遇到的第一道题。迁移一旦出错，损失往往比预想的大，而且很难原样挽回。所以阿里云数据迁移要做的，是把“搬数据”拆成几段能验证、能回退的动作。下面按选型、准备、执行、割接的顺序，说明每一段要盯住什么。
先定迁移类型
动手前先想清楚三件事：数据从哪里来，要搬到哪里去，业务最多能停多久。阿里云上常见的工具有数据传输服务 DTS、对象存储 OSS 自带的迁移能力，还有面向大体量离线数据的数据快递服务。各工具支持的数据库版本和存储类型会随产品更新调整，具体以阿里云官方文档为准，别凭以前的印象选。
按停机窗口看，一般分两类：
- 在线迁移：先全量拷贝，再持续同步增量。业务基本不停，适合数据库和在线交易系统。
- 离线迁移：停服后整体搬运，适合历史归档、冷数据，或者网络带宽本身不够的场景。
不少生产环境是两种方式混着用的：先在线同步存量和增量，业务低峰期短暂停写，追平最后一小段增量，再切换连接地址。
迁移前的准备
准备做得扎实，后面的返工就少。至少把下面几件事做完：
- 盘点数据：列出库表数量、数据总量、日增量，以及依赖它的上下游服务。漏掉一个对账脚本，切换后很容易才发现。
- 检查兼容性：字符集、存储过程、触发器、自增主键，以及目标端不支持的对象类型，都要逐项确认。
- 规划账号权限：迁移账号只给必要的读写和同步权限。密码放进密钥管理服务，别写进脚本或配置文件里。
- 实测网络：专线、VPN、公网的带宽和延迟差别很大。拿实际链路跑一遍，比按经验估算靠谱。
一个示例：电商订单库怎么搬
下面是一个示例场景，数字只用来说明步骤。换成你自己的项目时，要重新测。
假设某区域电商的订单库有 3 TB，每天新增约 2000 万条，晚上八点到十一点是业务高峰。团队最初想周末停服 6 小时整体迁移，但压测显示全量拷贝要 14 小时左右，停不起。
于是方案改成了这样：
- 周一到周五用 DTS 做全量加增量同步，源库照常服务。
- 每天凌晨比对源库和目标库的行数与校验和。两个分区的增量延迟偏高，于是单独拆出同步任务，延迟从几分钟降到几秒。
- 切换当天凌晨两点停止应用写入，等增量延迟归零，核对关键表的记录数和金额汇总，最后再改应用的数据库连接配置。
这个示例里，停写时间控制在 12 分钟以内，切换后源库保留只读 7 天，用作回滚。真正省时间的是提前把增量同步跑稳，切换当天只做收尾。
执行顺序和通过标准
正式执行时，建议按下面的顺序推进，每一步都要有明确的通过标准：
- 小批量试迁：挑一个非核心库或部分表，把整条链路跑通，记下耗时和报错。
- 全量迁移：放在业务低峰期启动，盯着源库负载和目标库写入速度。
- 增量同步：看延迟指标。延迟一直往上涨，先查大事务和没有主键的表。
- 数据校验：比对行数、主键范围和关键字段的聚合值。任务显示“成功”，不等于数据已经对了。
- 业务回归：让业务方在测试环境或灰度流量上跑一遍核心流程。
- 割接上线：按预案停写、追平、切换，然后观察。
割接前必须想好回滚
回滚方案要在割接前写完。常见做法是切换后保持反向同步，让数据在一段时间内还能同步回源库。一旦发现严重问题，连接可以很快切回原库，丢的数据也少。回滚至少演练一次。没演练过的团队，真到出问题那天，很难在压力下把操作一步步走完。
几个容易踩的坑
- 没有主键的表：增量同步容易重复或丢数。迁移前补上主键，或者先确认工具对这类表的处理方式。
- 字符集不一致：表情符号和生僻字可能被截断。试迁阶段就要用这些数据验证一遍。
- 自增值没调整：切换后如果自增起点没更新，新订单的主键可能和历史数据撞上。
- 定时任务和外部回调：报表任务、对账脚本、第三方回调地址，数据库搬完之后都要改。
小结
数据迁移顺不顺，取决于前期盘点是否细、中期增量同步是否稳、后期校验和回滚有没有预案。停机时间能压到多短，很大程度上看增量同步是否可靠。多花一天做试迁和演练，通常能让切换当天轻松不少。
