mysqldump + restore 不适合千万级跨云热迁移，因其单线程串行执行导致超时、锁表、OOM，无法捕获增量变更，停机窗口不可控，且高延迟公网下长连接极不稳定，全量导出导入期间业务受影响严重，变更数据完全丢失。
不能直接跨云厂商做 MySQL 实例级热迁移 —— 没有官方支持的“一键迁移实例”能力，所有所谓“热迁移”本质都是数据层迁移，必须绕过实例管控层，自己控制数据流与一致性边界。
为什么 mysqldump + restore 不适合千万级跨云热迁移
mysqldump 生成的是串行 SQL，单线程导出/导入，在千万级下极易超时、锁表、OOM；更关键的是，它无法捕获迁移过程中的增量变更，停机窗口不可控。跨云网络延迟高（尤其公网），mysqldump 的长连接极不稳定，中途失败就得重来。
- 导出阶段：全表
SELECT会触发大量临时表和排序，源库 CPU/IO 暴涨，影响线上业务 - 导入阶段：
mysql -e "source xxx.sql"是单事务回放，1000 万行可能卡死在一条大事务里 - 无增量衔接：dump 完成时刻到 restore 完成时刻之间的 binlog 变更完全丢失
真正可行的跨云热迁移路径：CDC + 流式同步
核心是用 CDC 工具解析源 MySQL 的 binlog，把变更事件实时转发到目标云 MySQL（或中间消息队列），再由消费者写入。整个过程源库只读不锁，目标库持续追平，最终只需秒级停机切流。
- 源端必须开启
binlog_format=ROW且binlog_row_image=FULL，否则 UPDATE/DELETE 无法还原完整行 - 推荐工具组合：
Flink CDC（强一致性、支持 checkpoint） 或Canal + Kafka（轻量、成熟，但需自行保障 exactly-once） - 目标云 MySQL 必须关闭
foreign_key_checks和sql_log_bin=0，避免写入时触发二次 binlog 或外键阻塞 - 注意字符集兼容性：源库若为
utf8mb4_unicode_ci，目标库建表时显式指定，避免 collation 冲突导致同步中断
如何处理跨云网络与权限限制
公有云 MySQL 实例默认禁止外网直连，且安全组/白名单策略严格。直接从目标云拉取源库 binlog 几乎不可能，必须反向部署 —— 把 CDC 客户端部署在源云 VPC 内，通过公网或云企业网（如阿里云 CEN、腾讯云 CCN）将变更数据推送到目标云 Kafka 或自建中转服务。
- 不要尝试开放源库 3306 端口到公网：风险高、延迟抖动大、易被限流
- 若源云不支持 VPC 对等连接，可用
SSH tunnel或Cloudflare Tunnel建立加密通道，但带宽上限明显，仅适合中小流量 - 目标写入端建议用连接池复用 + 批量
INSERT ... ON DUPLICATE KEY UPDATE，避免每条变更都建新连接 - 务必在目标端开启
innodb_buffer_pool_size至物理内存 70% 以上，否则大批量写入会频繁刷脏页，拖慢同步速度
跨云热迁移最难的不是技术选型，而是时间点控制：全量同步完成时刻、增量追平时刻、业务切流时刻，三者必须精确对齐。任何一环偏差都会导致主键冲突或数据跳变 —— 这部分没有银弹，只能靠前置压测 + 实时 lag 监控 + 切流前人工校验 SELECT COUNT(*) 和抽样 CHECKSUM TABLE 来兜底。
