必须用mydumper+myloader替代mysqldump，因其多线程导出压缩与并行导入可将200gb数据迁移压进30分钟；需正确配置线程数、压缩、事务一致性参数，并优化目标库导入性能及校验策略。
用 mydumper 替代 mysqldump，否则根本不可能压进30分钟
mysqldump 是单线程导出，200GB 数据跑满 10MB/s 也要 6 小时；导入更是逐条 INSERT，慢上加慢。哪怕数据只有 50GB，停机窗口也早超了。mydumper 支持多线程导出+压缩，myloader 多线程并行导入，是唯一能实测压进 30 分钟的逻辑迁移方案。
关键参数必须设对：
-
-t 8：线程数建议设为 CPU 核数的 1.5 倍，但不超过 16；太高反而因锁竞争拖慢 -
-c：启用压缩，减少磁盘 IO 和传输体积（尤其当目标库和源库不在同一机房） -
--trx-consistency-only：跳过FLUSH TABLES WITH READ LOCK，改用--single-transaction配合 InnoDB MVCC，避免长锁阻塞业务写入 - 导出路径务必落在 SSD 或高 IOPS 磁盘，别用系统盘或 NFS
导入前关掉目标库的非必要开销
默认配置下，myloader 导入会受 innodb_doublewrite、sync_binlog、foreign_key_checks 等机制严重拖累。不调，导入速度可能比导出还慢一倍。
导入前在目标库执行：
SET FOREIGN_KEY_CHECKS = 0;SET UNIQUE_CHECKS = 0;-
SET SQL_LOG_BIN = 0;（仅限从库或无 binlog 依赖场景） - 临时调大
innodb_buffer_pool_size（至少占可用内存 70%） - 确认
innodb_flush_log_at_trx_commit = 2，避免每条事务刷盘
导入完成后再恢复原值，并运行 ANALYZE TABLE 更新统计信息——这步漏掉，后续查询可能走错执行计划。
校验不能只看行数，得抽样比对内容哈希
停机窗口紧，没时间全量比对。但只查 COUNT(*) 容易漏掉空值处理差异、字符集截断、timestamp 自动转换等静默错误。
推荐组合校验：
- 对每个大表，用
SELECT MD5(GROUP_CONCAT(CONCAT_WS('|', col1, col2, ...))) FROM table_name抽 10 万行做哈希比对（注意字段顺序、NULL 处理一致） - 检查主键最大值、最小值、总行数三组数字，比对源库和目标库是否完全一致
- 随机选 3–5 张业务核心表，用
mysqldiff或自写脚本比对 100 条记录的完整字段值 - 特别留意
TIMESTAMP字段是否因时区配置不同而偏移；ENUM值是否因定义顺序变化导致隐式转换
切换前最后 5 分钟必须做的三件事
这三步不做，30 分钟窗口大概率崩在最后一分钟：
- 提前在目标库创建好应用用户，并验证
SHOW GRANTS FOR 'app_user'@'%'和源库完全一致（权限缺失会导致连接成功但查不到表） - 确认目标库
max_connections≥ 源库，且应用连接池配置已同步更新（否则切过去瞬间大量连接拒绝） - 在应用层关闭所有数据库连接池（如 HikariCP 的
close()），再启动新连接——别指望旧连接自动重连，很多框架会卡在 stale connection 上
真正危险的不是导出导入耗时，而是字符集隐式转换、权限继承遗漏、连接池未刷新这类“看不见的延迟”。它们不会报错，但会让业务在切流后几分钟才开始出问题。
