MySQL迁移成功需验证数据一致性、结构完整性、业务可用性三方面：一校验表结构（含ENGINE/CHARSET等）；二核对行数与关键字段分布并抽样比对；三测试权限、核心SQL及业务链路；四落实监控与回滚准备。
验证 MySQL 迁移是否成功，核心是确认数据一致性、结构完整性、业务可用性三方面。不能只看“服务起来没”，得真正比对“数据对不对、功能用不用得了”。
一、校验表结构是否一致
迁移前后数据库的表名、字段名、类型、长度、默认值、索引、主键、外键等必须完全匹配。忽略小差异（比如 ENGINE 类型不同）可能引发后续写入异常或性能问题。
- 用 mysqldump -d 导出源库和目标库的表结构（-d 表示只导结构），再用 diff 工具对比：
- mysqldump -h源IP -u用户 -p -d 数据库名 > schema_src.sql
- mysqldump -h目标IP -u用户 -p -d 数据库名 > schema_dst.sql
- diff schema_src.sql schema_dst.sql
- 重点关注：ENGINE、CHARSET、COLLATE、AUTO_INCREMENT 初始值、NOT NULL、DEFAULT 值是否一致；视图、存储过程、触发器也要单独检查（它们不包含在 -d 导出中）。
二、校验数据行数与关键字段分布
行数一致是最基础指标，但不足以证明数据正确——空表、全删后重插、主从延迟未刷盘都可能导致行数相同但内容错乱。需结合抽样校验。
- 对每张表执行 COUNT(*) 对比：
- SELECT COUNT(*) FROM 表名;（源库和目标库分别执行，结果应严格相等）
- 对高频查询字段（如主键、时间戳、状态字段）做聚合校验，例如：
- SELECT status, COUNT(*) FROM 订单表 GROUP BY status; —— 源/目标结果应完全一致
- 对大表可抽样比对：按主键取模或时间范围抽取 0.1%~1% 的记录，查 SELECT * 输出到文件，用 md5sum 或 sort + diff 比较（注意字段顺序、NULL 处理、时区、字符集隐式转换影响）。
三、校验业务逻辑与应用连通性
结构和行数都对，不代表能用。真实业务依赖关联查询、事务行为、权限配置、SQL 兼容性等，必须走通核心链路。
- 检查用户权限：用迁移后的账号连接目标库，执行 SHOW GRANTS，确保 SELECT/INSERT/UPDATE/DELETE 权限覆盖原库范围，特别注意 USAGE、SUPER、REPLICATION SLAVE 等特殊权限是否遗漏。
- 跑通关键 SQL：挑出应用中最常执行的 10–20 条 SQL（含 JOIN、子查询、GROUP BY、ORDER BY LIMIT），在目标库执行并核对结果集是否与源库一致（注意排序字段是否加了索引，避免因无序导致肉眼误判）。
- 模拟业务操作：用测试账号执行下单、支付回调、报表导出等典型事务，观察是否报错、响应时间是否明显变长、是否有死锁或锁等待加剧现象。
四、监控与回滚准备就绪
迁移不是“点一下就完事”，上线后 1–2 小时是风险高发期。校验必须包含可观测性和应急能力。
- 确认目标库已开启慢日志、错误日志、general_log（临时开启用于排查），且日志路径可访问；
- 检查监控项：QPS、TPS、连接数、InnoDB buffer hit rate、复制延迟（如为从库）、磁盘 IO 等是否在合理区间；
- 确保回滚方案已验证：备份快照可用、源库仍可读写、DNS 或配置切换脚本能 2 分钟内生效；
- 建议首次切流控制在低峰期，并设置 5–10 分钟灰度窗口（如只放 1% 流量），确认无异常再全量。
