目录一、前置准备迁移前必做1. 环境与资源评估2. 数据口径 校验规则3. 流量与风险预案二、标准四阶段迁移流程零停机通用架构阶段 1全量冷数据迁移存量同步业务不受影响阶段 2开启增量同步 双写核心保证数据不丢、不不一致阶段 3灰度切读逐步把读流量切到目标库风险最低阶段 4切写流量 下线源库收尾三、分场景专项优化亿级数据高频问题1. 分库分表架构迁移最常见2. 大表 / 超亿单表优化3. 冷热数据分离迁移4. 跨数据库类型迁移MySQL→PG/ClickHouse/ES 等5. 高并发写入场景四、主流工具选型生产落地五、核心避坑点生产事故高发区六、极简总结落地口诀核心思路双写兜底、逐步切流、灰度校验、旧数据渐进迁移、最终下线全程业务无感知、不中断服务分阶段落地。一、前置准备迁移前必做1. 环境与资源评估目标库算力、内存、磁盘、网络带宽扩容匹配亿级数据读写压力源库 / 目标库版本、字符集、排序规则、字段类型完全对齐。带宽存量全量迁移会产生大量 IO隔离迁移流量与业务流量避免抢占资源。元数据对齐表结构、索引、约束、触发器、分区、存储过程、权限、路由规则提前统一禁止迁移中改表。2. 数据口径 校验规则定义数据一致性标准行数、主键、唯一索引、核心字段、增量变更时序。准备校验工具行级比对、抽样比对、全量对账脚本提前压测校验性能。梳理业务读写链路读多 / 写多、热点表、大字段、冷热数据、定时任务、MQ / 缓存联动逻辑。3. 流量与风险预案限流、熔断、回滚方案、应急切换脚本全流程压测模拟亿级存量 实时增量。缓存预热规则防止切流后缓存击穿。二、标准四阶段迁移流程零停机通用架构阶段 1全量冷数据迁移存量同步业务不受影响目标把历史存量数据从源库一次性同步到目标库不影响在线读写。选择低峰窗口凌晨业务低谷使用离线批量同步工具MySQLmysqldump/mydumper并行导出、DataX、Canal Dump、DTS 全量模式大数据 / 数仓Spark/Flink 离线任务、Sqoop优化迁移参数分库分表 / 分区拆分迁移禁止单表亿级全表扫按主键 / 时间范围分片并行同步。限速、分批提交控制源库 CPU、IO 负载避免拖垮线上。同步完成后第一轮全量数据校验核对总行数、抽样明细、索引有效性。关键点此时业务仍只读写源库目标库仅做镜像。阶段 2开启增量同步 双写核心保证数据不丢、不不一致全量同步完成后源库已产生新增量数据必须补追增量再开启双写。增量追平用增量同步组件Canal、Debezium、RocketMQ Binlog、数据库 DTS监听源库 Binlog实时同步新增 / 更新 / 删除到目标库直到双库数据完全追平、延迟趋近于 0。应用层开启双写最稳妥方案改造业务代码 / 中间件写操作同时写入源库 目标库规则写入优先级源库优先落库目标库写入失败不阻塞主流程日志告警、重试队列兜底。幂等设计主键 / 唯一键防重复写入避免双写产生脏数据。关闭自动自增冲突统一 ID 生成器雪花 ID、号段模式禁止数据库自增主键双写冲突。运行观察持续监控双库延迟、写入成功率、报错日志稳定运行数小时数天根据业务量级。备选方案不改代码中间件层双写Sharding-JDBC、Proxy、数据库触发器生产不推荐触发器性能差、死锁风险高。阶段 3灰度切读逐步把读流量切到目标库风险最低双写稳定、数据一致后先切读、后切写灰度放量出现问题立刻回滚。灰度策略由小到大按用户 ID 分片、地域、接口、应用集群比例切流0% → 10% → 30% → 50% → 100%热点数据、核心接口最后切换。监控指标 响应耗时、错误率、慢 SQL、缓存命中率、双库数据差异、Binlog 延迟。异常回滚一旦出现查询异常、数据不一致一键切回源库读。读流量全量切到目标库后再稳定观察一段时间。阶段 4切写流量 下线源库收尾切写流量逐步关闭应用双写将写操作完全切换到目标库源库不再接收新写入。最后一轮全量校验确认双库数据 100% 一致无遗漏、无脏数据。下线流程停止 Binlog 增量同步、同步任务源库保留7~30 天冷备、回滚兜底逐步下线源库连接、权限、监控最终销毁 / 归档。三、分场景专项优化亿级数据高频问题1. 分库分表架构迁移最常见方案 1同规则迁移分片键、分片算法不变逐分片迁移、逐分片切流。方案 2重分片 / 扩容分片规则变更 先全量 增量同步到新分片集群 → 双写新旧分片 → 灰度切读 → 切写全程保证路由正确。2. 大表 / 超亿单表优化按时间范围、主键区间拆成分批任务避免全表扫描锁表、IO 打满。迁移前临时关闭非必要索引加速导入导入完成再重建索引生产常用。禁止在线ALTER TABLE迁移期间表结构冻结。3. 冷热数据分离迁移冷数据离线批量迁移低峰热数据Binlog 增量实时同步 双写优先保障热点行。4. 跨数据库类型迁移MySQL→PG/ClickHouse/ES 等额外做字段类型映射、函数兼容、SQL 语法适配增量同步做数据转换清洗前置 ETL 校验读接口单独适配灰度验证查询逻辑。5. 高并发写入场景双写阶段增加异步重试队列目标库抖动不影响主业务迁移任务限速和业务流量错峰关闭源库慢查询日志、全量日志降低负载。四、主流工具选型生产落地环节常用工具适用场景全量导出导入mydumper/loader、DataX、DTSMySQL 亿级存量迁移增量 Binlog 同步Canal、Debezium、阿里云 / 云厂商 DTS实时增量追平双写 / 流量路由业务代码、ShardingSphere、网关应用层 / 中间件层切流数据校验pt-table-checksum、自定义对账脚本行级 / 全量一致性校验大数据迁移Flink/Spark、Sqoop数仓、非关系型库五、核心避坑点生产事故高发区不要先切写再切读一旦目标库故障直接全线宕机顺序必须「双写→切读→切写」。忽略 ID 冲突自增主键、唯一索引在双写时极易重复统一分布式 ID 是前提。索引缺失迁移后忘记重建索引导致目标库查询超时。只抽样不做全量校验亿级数据抽样无法发现零星丢数、错数。迁移后立刻删除源库必须留观察期保留兜底数据源。触发器 / 存储过程不同步隐性逻辑不一致引发业务异常。六、极简总结落地口诀先全量迁存量Binlog 追增量应用开启双写保一致灰度逐步切读稳定再切写多轮校验源库留底再下线。整套方案全程服务不中断、业务无感知是互联网、金融、大数据领域亿级数据迁移的标准落地范式。