MySQL迁移环境测试的核心是确保数据一致性、业务功能正常、性能达标，而不是只看服务能不能启动。
数据完整性验证
这是迁移验证的首要环节。必须核对源库和目标库的数据行数、关键字段值、索引结构、外键约束是否一致。
用SELECT COUNT(*)比对各表总行数（注意WHERE条件是否一致，避免误判） 对核心表抽样校验：如取ID为1000、5000、9999的几条记录，逐字段比对内容（含时间戳、枚举值、NULL处理） 检查SHOW CREATE TABLE结果，确认字符集（如utf8mb4）、排序规则、自增起始值、默认值等未被篡改 验证主从关系或读写分离配置是否按预期重建（如有）SQL兼容性与功能回归
不同MySQL版本或迁移工具可能引发语法/行为差异，需覆盖真实业务SQL路径。
提取应用日志中高频执行的SELECT、INSERT、UPDATE、DELETE语句，在新环境重放并观察执行计划（EXPLAIN）是否合理 重点测试存储过程、函数、触发器——它们容易因版本升级（如5.7→8.0）报错或逻辑偏移 验证事务边界行为：比如跨表更新+回滚、长事务锁表现、死锁检测机制是否与原环境一致 检查慢查询日志是否开启、阈值是否匹配，确认监控链路已接入性能基线对比
不能只看“能跑”，要看“跑得怎么样”。需在相同压力下对比关键指标。
使用sysbench或业务自有压测脚本，对相同表结构执行QPS、TPS、平均响应时间对比 关注高并发场景下的连接池表现（如max_connections是否足够、wait_timeout设置是否合理） 检查InnoDB缓冲池命中率（Innodb_buffer_pool_hit_rate）、查询缓存（如启用）有效性 对比大字段（TEXT/BLOB）读写、JOIN多表关联、GROUP BY聚合等典型操作耗时变化高可用与灾备联动验证
单点能用不等于可上线。必须验证故障转移、备份恢复等兜底能力。
模拟主库宕机，验证VIP漂移、DNS切换或代理（如ProxySQL/HAProxy）是否在预期时间内完成接管 从最新备份还原一个独立实例，验证xtrabackup或mysqldump备份可恢复且数据完整 检查binlog位置是否连续、GTID是否启用并同步正常（尤其跨版本迁移时GTID兼容性易出问题） 确认监控告警（如CPU、连接数、复制延迟）已在新环境准确触发迁移不是一次性的导入导出，而是一套闭环验证动作。每个环节都要有明确通过标准，不能凭“看起来没问题”就放行。
