保证MySQL迁移数据一致性需分四阶段验证：迁移前校验结构与元数据，迁移中基于binlog实现增量同步，迁移后通过pt-table-checksum等工具行级比对，上线前结合业务流量验证逻辑正确性与高可用。
迁移 MySQL 数据库时，保证数据一致性是核心目标。关键不在于“是否迁移完成”，而在于“源库和目标库的每一条记录、每一个字段、每一行数据是否完全相同”。校验必须覆盖结构、内容、索引、约束等维度，且需在迁移前后、甚至迁移中分阶段验证。
迁移前：结构与元数据一致性检查
结构不一致会导致后续数据写入异常或查询结果偏差。需逐项比对：
- 表名、字段名、字段类型（注意 TINYINT(1) 和 BOOLEAN 的映射差异）、长度、是否允许 NULL、默认值
- 主键、唯一索引、普通索引的定义（包括顺序、方向、表达式索引）
- 外键约束（尤其注意级联动作、ON DELETE 行为是否兼容）
- 字符集与排序规则（如 utf8mb4_unicode_ci vs utf8mb4_0900_as_cs）
推荐使用 mysqldiff（MySQL Utilities）或 pt-table-checksum 的结构比对模式，也可导出 SHOW CREATE TABLE 后用 diff 工具人工比对。
迁移中：增量同步与断点续传保障
全量迁移后到切换前存在时间窗口，业务持续写入，必须捕获并同步这部分变更：
- 基于 binlog 位点（File + Position 或 GTID）做增量同步，确保源库所有 DML/DDL 都被目标库重放
- 使用 pt-table-sync 或 MyDumper + MyLoader 搭配 binlog 回放工具（如 canal、maxwell、Debezium）实现准实时同步
- 记录迁移开始时的 binlog 位置，在全量导入完成后立即启动增量同步，并确认无延迟（Seconds_Behind_Master = 0）
迁移后：行级数据一致性校验
这是最刚性的验证环节，不能只查 count(*) 或 sum(id) —— 它们无法发现错行、乱序、字段值错误等问题：
- pt-table-checksum 是业界标准方案：在源库计算每张表的校验和（按 chunk 分片），将结果写入专用 checksum 表；再用 pt-table-sync --sync-to-master 在目标库比对，自动定位不一致的 chunk 范围
- 对小表可直接用 SQL 校验：SELECT MD5(CONCAT_WS('#', col1, col2, ...)) AS hash FROM table ORDER BY pk，分别在源/目标库执行并比对 hash 集合
- 重点校验逻辑主键（如订单号+时间戳）、金额类字段、JSON 字段（注意空格、转义、排序差异）、TEXT/BLOB 类型（避免截断）
上线前：业务逻辑与边界场景验证
技术一致 ≠ 业务可用。需结合真实流量或影子流量验证：
- 抽样高频查询语句（含 JOIN、GROUP BY、ORDER BY、LIMIT）在新旧库执行，比对结果集行数、字段值、排序顺序
- 验证事务行为：跨表更新、存储过程、触发器、自增 ID 分配是否符合预期
- 检查慢查询日志、锁等待、连接数突增等异常指标，确认新环境未引入性能退化
- 模拟故障切换（如主动 kill 主库进程），验证高可用机制是否正常接管且数据无丢失
