MySQL数据恢复从来不是终点，真正的挑战在于恢复之后你敢不敢直接把库切回生产环境。很多团队在完成恢复操作后，只是草草看一眼表记录数或者随便跑几条SELECT就认为数据回来了，这种粗糙的验证方式往往导致业务上线后出现数据逻辑错误、索引损坏或者主从同步异常。完整性校验必须覆盖物理完整性、逻辑一致性和业务语义正确性三个维度，缺一不可。
物理层校验：先确认文件没有硬伤恢复完成后第一件事不是连数据库，而是检查数据文件的物理状态。MySQL的数据最终存储在磁盘上的ibd文件、frm文件以及各种日志文件中，如果恢复过程中拷贝不完整或者磁盘本身有坏道，上层查询可能暂时正常，但读到损坏页时就会触发crash。
执行CHECK TABLE tablename EXTENDED;是基础操作，但很多人不知道EXTENDED选项会逐页检查索引和数据页的一致性，比不加参数要严格得多。对于InnoDB表，这个命令会检查页的校验和、页目录的完整性以及记录头信息是否正确。如果数据库规模较大，逐表执行CHECK TABLE耗时很长，可以写脚本批量处理，重点关注那些恢复前就存在坏块的表。
更深入的做法是使用innochecksum工具直接对ibd文件做校验。这个工具独立于MySQL进程运行，可以检测页的checksum是否匹配、是否存在损坏的页类型标记。命令很简单：innochecksum /var/lib/mysql/dbname/table.ibd。如果输出中出现“FAIL”字样，说明物理页已经损坏，必须重新从备份恢复该表，不能抱侥幸心理。
还有一个容易被忽略的细节是表空间ID的匹配。如果你是通过拷贝ibd文件方式恢复的表，必须确认该ibd文件中的space_id与InnoDB数据字典中记录的一致。不一致时MySQL会在错误日志中输出“Tablespace id mismatch”警告，此时虽然能打开表，但写入操作可能导致数据进一步损坏。通过SHOW ENGINE INNODB STATUS;查看LATEST FOREIGN KEY ERROR和LATEST DETECTED DEADLOCK段，也能发现一些隐藏的表空间问题。
物理结构没问题不代表数据逻辑正确。恢复过程中如果使用了时间点恢复，可能存在事务不完整的情况；如果是从主从复制中断点恢复，可能丢失了部分binlog事件。逻辑校验的核心是确认数据内部关系没有断裂。
首要检查自增主键的连续性。执行SELECT MAX(id) FROM table;和SELECT COUNT(*) FROM table;对比，如果两者差距异常大，说明恢复过程中可能有大量插入失败或者回滚。更精确的做法是检查自增值本身：SHOW CREATE TABLE tablename;看AUTO_INCREMENT值是否合理。如果AUTO_INCREMENT值远大于实际最大id，后续插入会浪费大量主键空间，虽然不影响数据正确性，但需要评估业务影响。
索引一致性检查是重头戏。恢复后索引文件可能与数据文件不同步，特别是使用快速索引重建或者并行恢复工具时。执行CHECK TABLE tablename QUICK;可以快速验证索引是否完好，但QUICK模式只检查索引树的链接正确性，不逐条比对索引记录与数据行。如果怀疑索引内容有误，需要用ANALYZE TABLE tablename;重建索引统计信息，然后对比执行计划是否与恢复前一致。一个实用技巧是随机抽取一些主键值，分别通过主键查询和二级索引查询，对比返回结果是否相同。
外键约束的验证往往被忽视。如果恢复的表涉及外键关系，必须执行SELECT * FROM child_table WHERE foreign_key NOT IN (SELECT primary_key FROM parent_table);这类查询来发现孤儿记录。恢复过程中如果父表数据被截断或者部分恢复，子表就会出现悬挂引用，业务逻辑会因此出错。同样，唯一约束也需要验证，执行SELECT unique_column, COUNT(*) FROM table GROUP BY unique_column HAVING COUNT(*) > 1;能快速发现重复数据。
数据页级别的校验可以使用SELECT COUNT(*) FROM table FORCE INDEX (primary);和SELECT COUNT(*) FROM table FORCE INDEX (secondary_index);对比，如果两个数字不同，说明二级索引中存在指向不存在数据行的指针，这是典型的索引损坏症状，需要重建索引。
记录数一致不代表数据内容一致。MySQL提供了CHECKSUM TABLE tablename;命令来计算表的校验和，但这个校验和基于存储引擎的实现，不同版本之间可能不兼容。更可靠的方法是自己计算行级校验和。
对于关键业务表，恢复后应该计算每一行的MD5或者CRC32值，与备份前的快照进行对比。如果之前没有保存快照，至少要在恢复后立即计算并记录，作为后续验证的基准。具体操作可以通过SELECT MD5(CONCAT_WS('|', col1, col2, col3)) FROM table ORDER BY id;生成每行的哈希值，然后导出到文件用diff工具对比。这个操作虽然耗时，但对于金融、交易类系统是必须的。
针对大表的抽样校验更实际。可以按主键范围分批次计算校验和，比如每10万行计算一个聚合值，然后与备份来源库的对应范围比对。如果发现某个范围的校验和不一致，再缩小范围定位具体行。这种方法在保证覆盖度的同时大幅减少校验时间。
时间字段的合理性检查也很重要。恢复后的数据中，create_time、update_time等字段不应该出现未来时间或者早于业务上线时间的情况。执行SELECT MIN(create_time), MAX(create_time) FROM table;与业务记录的时间线对比，能发现恢复过程中时间戳被篡改或者时区转换错误的问题。
即使物理和逻辑层面都通过了校验，数据仍然可能在业务层面出错。比如订单金额总和与财务记录对不上，用户余额出现负数，或者库存数量与出入库流水不一致。这类问题需要结合业务规则编写专门的校验SQL。
典型的业务校验包括：账户余额不能为负、订单状态流转必须符合状态机、汇总表与明细表金额一致、关联记录的双向引用完整。例如在电商系统中，可以执行SELECT order_id, SUM(item_amount) FROM order_items GROUP BY order_id HAVING SUM(item_amount) != (SELECT total_amount FROM orders WHERE orders.id = order_items.order_id);来发现金额不一致的订单。
恢复后还应该跑一遍业务核心流程的端到端测试。不是简单的功能测试，而是用真实数据验证关键事务能否正常提交、回滚，触发器是否正确触发，存储过程执行结果是否符合预期。很多团队会准备一套业务校验脚本，在数据恢复后自动执行，覆盖所有核心业务场景。
主从复制一致性校验如果恢复的数据库是主库或者需要重新加入复制拓扑，主从一致性校验是绕不过去的环节。恢复后的主库与从库之间可能存在数据差异，直接开启复制会导致从库应用binlog时出错。
使用pt-table-checksum工具是业界标准做法。这个工具会在主库上创建校验表，将表分块计算校验和，然后通过复制传递到从库执行相同计算，最后对比差异。执行命令大致为：pt-table-checksum --replicate=percona.checksums --databases=dbname h=master_host。工具会自动处理负载控制，不会锁表。检查结果中如果出现“DIFFS”列不为0的情况，说明该块数据主从不一致，需要用pt-table-sync修复。
如果没有安装Percona Toolkit，也可以手动校验。在主库上对关键表执行SELECT COUNT(*), SUM(CRC32(CONCAT_WS('#', col1, col2))) FROM table;，然后在从库执行相同语句对比结果。这种方法虽然粗糙但能快速发现明显差异。需要注意的是，手动校验期间要确保主库没有大量写入，否则校验结果没有意义。
GTID一致性同样需要验证。恢复后的数据库如果启用了GTID，执行SHOW GLOBAL VARIABLES LIKE 'gtid_executed';查看已执行的GTID集合，与备份时的GTID位置对比，确认恢复覆盖了正确的事务范围。如果发现GTID空洞，说明有事务没有被恢复，需要从binlog中补执行。
靠人工逐项检查效率低且容易遗漏，应该将完整性校验流程脚本化。一个完整的自动化校验脚本应该包含以下步骤：先检查MySQL错误日志中是否有恢复后的报错信息；然后遍历所有表执行CHECK TABLE EXTENDED并记录结果；接着对核心业务表执行行数统计和校验和计算，与基准值对比；再运行预设的业务规则校验SQL；最后输出一份汇总报告，明确标注通过和失败的检查项。
校验脚本的设计需要注意几个细节。一是超时控制，大表的CHECK TABLE可能执行数小时，需要设置合理的超时时间并在超时后记录警告而非直接失败。二是并发控制，多个CHECK TABLE同时执行会消耗大量IO资源，应该控制并发数。三是结果持久化，每次校验的结果都应该存入专门的校验记录表，方便追溯历史变化。
对于特别大的表，全量校验不现实，可以采用增量校验策略。每次恢复后只校验自上次校验以来有变更的分区或者时间范围，全量校验则安排在业务低峰期定期执行。这种分层校验机制在保证数据安全的同时不影响恢复效率。
恢复后的完整性校验本质上是对备份恢复流程的质量把关。一次不完整的校验可能让有缺陷的数据流入生产环境，造成的业务损失远超恢复操作本身。建立严格的校验标准并持续执行，才是数据恢复工作的完整闭环。
