MySQL异常恢复后需验证数据完整性与服务可用性：检查服务状态与连通性、核对表结构一致性、抽样校验核心表数据、验证业务逻辑执行正确性。
MySQL异常恢复后，验证数据完整性和服务可用性是关键一步。不能只看服务是否启动、能否连接，更要确认数据没丢、没乱、逻辑一致。
检查服务状态与基础连通性
先确认MySQL进程已正常运行，端口可访问，且能成功登录：
- 执行 systemctl status mysqld（或 service mysql status）查看服务状态
- 用 mysql -u root -p -h 127.0.0.1 -P 3306 尝试连接，避免仅用 socket 连接掩盖网络或端口问题
- 运行 SELECT VERSION(), NOW(); 确认实例响应正常、时间无异常偏移
核对关键元数据与表结构一致性
恢复后最易被忽略的是表结构是否与备份时一致，尤其字段增删、索引变更、字符集调整等：
- 对比恢复库与备份记录中的 SHOW CREATE TABLE 表名; 输出，重点关注 ENGINE、CHARSET、COLLATE、AUTO_INCREMENT 值
- 检查 information_schema.TABLES 中的 TABLE_ROWS（注意：InnoDB 下为估算值，仅作参考）和 DATA_LENGTH，与恢复前快照比对趋势是否合理
- 运行 SELECT COUNT(*) FROM 表名 LIMIT 1; 快速确认表可查询，避免因损坏导致 SELECT 卡死或报错
抽样校验核心业务表的数据完整性
全量比对不现实，应聚焦高频、关键、有业务含义的表，结合主键/时间字段做分段抽样：
- 对订单、用户、交易类表，按 WHERE id % 100 = 0 或 created_at > '2024-01-01' 抽取千分之一样本，导出后与备份库对应结果 md5sum 对比
- 使用 pt-table-checksum（Percona Toolkit）在主从或双库间自动校验，适合中大型环境；若无从库，可临时拉起一个只读实例做对比
- 重点检查自增主键是否跳变、唯一索引冲突是否引发插入失败、TEXT/BLOB 字段内容是否截断（如中文乱码、长度突降）
验证业务逻辑层面的可用性
数据库层面“看起来正常”，不代表应用能正确使用。需模拟真实调用路径：
- 运行核心业务 SQL：如用户登录（查账号+密码哈希）、下单（INSERT 订单 + UPDATE 库存）、报表统计（复杂 JOIN + GROUP BY）
- 检查慢查询日志（slow_query_log=ON）中是否有异常长耗时语句，可能暗示索引失效或统计信息未更新
- 触发一次 ANALYZE TABLE 更新统计信息，再观察执行计划（EXPLAIN）是否与恢复前一致
恢复不是终点，验证才是上线前最后一道防线。数据没丢不等于数据没坏，结构没变不等于逻辑没崩。多一层校验，少一次回滚。
