迁移 MySQL 数据库时确保零数据丢失，核心在于一致性备份 + 可验证的同步 + 停机窗口精准控制。不是简单导出再导入，而是要兼顾主从状态、事务完整性、字符集兼容性和应用连接切换的安全性。
一、停机迁移：适合中小库，操作简单但需业务暂停
适用于数据量小于 100GB、可接受分钟级停服的场景。关键在锁表 + 快照式导出，避免备份过程中写入导致不一致。
使用mysqldump加
--single-transaction --routines --triggers --events参数，对 InnoDB 表保证事务一致性；对 MyISAM 表需加
--lock-all-tables导出前执行
FLUSH TABLES WITH READ LOCK;（仅限短停机），再
SHOW MASTER STATUS;记下 binlog 位置，用于后续比对 导入目标库后，用
SELECT COUNT(*)和
CHECKSUM TABLE校验关键表行数与数据哈希值
二、主从切换迁移：零丢数据，适合中大型生产环境
通过构建新库为主从架构中的从节点，追平主库后提升为新主，实现平滑切换。
在目标服务器部署 MySQL 实例，配置server-id，开启
log-bin（便于后续反向同步或故障回切） 用
mysqldump --all-databases --master-data=2导出源库并导入目标库，该参数自动记录 binlog 位置 启动复制：
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;，再
START SLAVE;确认
Seconds_Behind_Master = 0且
Slave_SQL_Running = Yes后，停止写入源库，执行
STOP SLAVE;，将目标库提升为主库
三、校验与回滚准备：迁移后必须做的三件事
迁移完成不等于安全落地，数据一致性和服务可用性必须双重验证。
结构比对：用mysqldbcompare（MySQL Utilities）或开源工具
pt-table-checksum扫描全库表结构与索引差异 数据抽样校验：对订单、用户等核心表，按时间/ID区间抽取 5–10 个批次，对比源和目标的
SELECT MD5(CONCAT(...))结果 保留回滚通道：迁移后 48 小时内，保持原主库只读并开启 binlog；若发现问题，可通过
mysqlbinlog回放增量日志快速恢复
四、避坑提醒：这些细节常导致“看似成功实则丢数据”
很多迁移失败源于隐性配置冲突或权限疏漏，不是技术难度高，而是检查不到位。
字符集不一致：SHOW CREATE TABLE查源表，确认目标库
character_set_database和表级
CHARSET完全匹配，尤其含 emoji 或多语言字段 SQL_MODE 差异：源库若启用
STRICT_TRANS_TABLES，目标库也需一致，否则插入截断不报错，造成静默丢数据 外键约束未禁用：跨库导入时，先
SET FOREIGN_KEY_CHECKS=0;，导入完成再开，否则因依赖顺序失败 时间戳字段行为：
TIMESTAMP默认随系统时区变化，迁移前后确认
time_zone设置一致，或改用
DATETIME真正安全的迁移，不靠一次操作多快，而靠每一步是否可验证、可中断、可回退。把校验当成迁移的一部分，而不是最后才想起来的事。
