MySQL迁移唯一稳妥路径是主从同步+切读写流量，需先让新库成为旧库从库并确认GTID完全对齐、Seconds_Behind_Master连续5分钟为0且SQL线程活跃，再通过中间件双写验证数据一致后分步切流，并确保连接池优雅重连。
主从同步 + 切读写流量是唯一稳妥路径
MySQL 迁移过程中应用不能停，核心矛盾是「数据一致性」和「服务连续性」的平衡。单靠 mysqldump 或逻辑导出必然锁表或延迟高，生产环境必须走主从复制路径。迁移不是“把旧库数据拷一份到新库”，而是让新库先成为旧库的从库，等同步追平后再切换流量。
切流前必须验证 Seconds_Behind_Master 稳定为 0
只看 SHOW SLAVE STATUS 输出里 Seconds_Behind_Master 是 0 不够，要连续观察 5 分钟以上，且 Slave_SQL_Running_State 显示 executing the query 或类似活跃状态。常见坑是：网络抖动导致 IO 线程断连但 SQL 线程还在跑，表面为 0 实际已停止同步；或者开启了 slave_parallel_workers，但 Seconds_Behind_Master 在并行回放时不准，需结合 Retrieved_Gtid_Set 和 Executed_Gtid_Set 对比确认 GTID 完全一致。
读写分离中间件（如 ShardingSphere、MyCat）切换配置需双写兜底
如果应用层不直连 MySQL，而是通过中间件路由，切流不能只改中间件配置。必须先开启双写：所有写请求同时发往新旧库，用 binlog 或轻量级比对工具（如 pt-table-checksum）验证两边数据一致；确认无误后，再将中间件的写流量切到新库，读流量可提前切（因主从延迟可控）。跳过双写直接切写流量，一旦新库主键冲突、触发器缺失或字符集不一致，数据就不可逆损坏。
应用连接池必须支持优雅关闭与重连
切流时旧库连接需释放，新库连接要建立，这依赖连接池行为。HikariCP 默认 connection-timeout 是 30 秒，若新库未就绪，应用会卡住甚至超时失败。务必设置 initialization-fail-fast=false，并启用 connection-test-query 或 validation-timeout，确保连接建立后能真实执行 SELECT 1。另外，JDBC URL 中必须加 useSSL=false&allowPublicKeyRetrieval=true（MySQL 8.0+），否则 TLS 握手失败会导致连接池初始化卡死。
真正难的不是迁移动作本身，而是验证——验证主从 GTID 是否完全对齐，验证双写期间有没有被忽略的存储过程调用，验证应用缓存是否在切流瞬间击穿。这些点没盯住，迁移完成那一刻就是故障开始的时候。
