最可靠验证是在恢复后用mysqlcheck检查表状态，而非校验备份文件本身；它可快速发现表损坏、行数异常等问题，但不校验每行内容。
用 mysqlcheck 验证备份恢复后的表结构和行数是否一致
备份文件本身是二进制或 SQL 文本，不能直接“校验完整性”——真正要验证的是：恢复后数据是否和原库一致。最轻量、最常用的做法是恢复到测试库，再用 mysqlcheck 快速比对表状态。
它不校验每行内容，但能快速发现表损坏、引擎不匹配、行数异常等高频问题：
-
mysqlcheck -u root -p --check --extended db_name table_name：检查单表（含行数、索引一致性） -
mysqlcheck -u root -p --analyze db_name：更新统计信息，辅助判断行数是否合理 - 注意：若备份时用了
--single-transaction，但恢复后某表行数明显偏少，大概率是备份过程中有长事务阻塞，导致部分数据未被快照捕获
用 mysqldump 的 --tab + md5sum 做物理层粗略校验
当备份是纯文本 SQL（如 mysqldump 输出），无法用哈希比对——SQL 文件顺序、注释、时间戳都可能不同。但如果你用 --tab 导出为 CSV/TSV（即数据与建表语句分离），就可以对数据文件做哈希校验。
适用场景：ETL 流程中需要确认导出文件未被截断或传输损坏：
-
mysqldump --tab=/tmp --fields-terminated-by=',' db_name table_name生成/tmp/table_name.txt - 导出后立即执行
md5sum /tmp/table_name.txt > /tmp/table_name.md5 - 恢复前重新计算并比对：
md5sum /tmp/table_name.txt是否与原始.md5一致 - ⚠️ 坑：
--tab要求 MySQL 用户有FILE权限，且只支持 MyISAM 和某些配置下的 InnoDB；InnoDB 表用此方式导出可能丢失事务边界
用 pt-table-checksum 校验主从或跨库间数据逻辑一致性
这是 Percona Toolkit 提供的成熟方案，专为“备份恢复后是否和源库数据一致”而生。它不依赖文件哈希，而是按 chunk 计算校验和，适合大表、高并发环境。
关键点在于：它校验的是「逻辑一致性」，不是文件完整性：
- 必须在源库（或备份恢复后的库）上运行：
pt-table-checksum --host=127.0.0.1 --user=u --password=p h=127.0.0.1,u=u,p=p --databases=db_name - 结果写入
percona.checksums表，再用pt-table-sync --print查看差异行 - ⚠️ 坑：默认会锁表（
--lock-wait-timeout=120可缓解），且要求所有表有主键或唯一键；无主键表会被跳过，容易漏检 - 不适用于单机单库的“本地备份自检”，更适合主从同步验证或迁移后比对
为什么不能只靠 gunzip -t 或 zcat xxx.sql.gz | head -n1？
很多人用 gunzip -t backup.sql.gz 确认压缩包没损坏，再用 head 看开头是否有 CREATE TABLE ——这只能说明文件可解压、开头语法合法，完全无法覆盖真实风险。
常见失效场景：
- gzip 尾部损坏，
-t仍返回 0（gzip 设计如此，只校验头部和部分块） - 备份中途磁盘满，
mysqldump写入了截断的 SQL，但最后一行可能是合法的INSERT，head看不出 - 字符集不一致导致乱码插入，
mysql客户端执行不报错，但数据已失真 - 最隐蔽的坑：备份时用了
--skip-triggers却忘了恢复时补上，业务逻辑悄然出错
真正可靠的验证，永远发生在「恢复之后」，而不是备份文件生成那一刻。哪怕加了 --set-gtid-purged=OFF 或 --hex-blob，也得把库跑起来查几条关键记录。
