数据恢复后需验证完整性，先核对表结构、索引、视图等对象是否一致，再通过统计行数、抽查关键数据确认数量完整，检查自增ID连续性，验证外键关联与业务逻辑正确性，最后进行应用层访问测试，确保结构、数据、关联和功能均正常。
MySQL数据恢复后，验证数据完整性是确保恢复操作成功的关键步骤。不能假设备份还原后数据就一定完整可用，必须通过系统性检查来确认表结构、记录数量、关键业务数据和约束关系是否正常。
核对表结构与索引
恢复后的数据库应与原库保持一致的结构。可通过以下方式比对：
- 使用 SHOW CREATE TABLE 表名; 查看恢复后各表的建表语句，并与备份前记录或生产环境对比，确认字段类型、默认值、自增设置等一致
- 检查索引是否存在且正确，执行 SHOW INDEX FROM 表名; 确保主键、唯一索引、普通索引未丢失
- 视图、存储过程、触发器等对象也需确认存在并可正常调用
统计行数与关键字段数据
快速判断数据是否完整的基本方法是比较记录数量：
- 对核心业务表执行 SELECT COUNT(*) FROM 表名;，并与备份时或原系统中的记录数进行比对
- 抽查特定时间段或关键ID范围的数据是否存在，例如：查询最近一周订单是否齐全
- 检查最大自增ID是否连续或符合预期，避免出现数据截断
验证外键与业务逻辑关系
数据之间的关联性是完整性的重点：
- 若有外键约束，确认父子表数据匹配，如订单中的 user_id 是否都能在用户表中找到对应记录
- 运行一些典型业务查询，比如“某用户的全部订单及详情”，验证多表联拟能否正常返回结果
- 检查金额、状态流转等关键字段是否有异常值（如负数、空值、非法状态）
应用层简单访问测试
最终的数据可用性体现在应用程序能否正常使用：
- 连接应用到恢复库，尝试登录、查看列表、提交表单等基础操作
- 观察日志是否报错，特别是SQL错误或找不到记录的异常
- 如有条件，可在测试环境做一轮冒烟测试，覆盖主要功能流程
基本上就这些。只要结构对、数量对、关联对、应用能用，就可以认为数据恢复基本完整。定期演练恢复流程并建立校验清单，能大幅降低线上事故风险。
