必须在备份完成瞬间立即执行md5sum生成校验文件并落盘，恢复前严格用md5sum -c验证；否则无法捕获磁盘写入失败、NFS中断等导致的静默截断，且人工比对或延迟校验均不可靠。
备份完成后立刻算MD5，别等恢复时再补
文件写完就校验，是唯一能抓住静默损坏的窗口。磁盘写入失败、NFS挂载中断、OOM杀进程——这些都可能让mysqldump输出截断，但命令仍返回0。你得在文件还热乎、没离开源机器时，立刻执行：
md5sum backup.sql > backup.sql.md5。不是看屏幕输出，不是人工抄写，必须落盘成文件。如果用
gzip压缩，校验对象是backup.sql.gz，不是解压后的SQL。
恢复前必须用md5sum -c验证，不能跳过
md5sum -c backup.sql.md5才是正确姿势，它会读取.md5文件里的哈希值并比对，同时检查文件是否存在、是否可读。常见错误包括：
- 路径不对，
backup.sql.md5不在当前目录，报错md5sum: backup.sql.md5: no properly formatted MD5 checksum lines found - 权限问题，
backup.sql被设为只读，md5sum -c读不了，直接FAIL - 误以为“文件能
cat出来就没事”，但部分损坏的SQL可能前几万行语法合法，导入到一半才报错，表建了、数据漏了一半
backup.sql: OK才能进下一步；FAILED就停手，查磁盘、查挂载、查备份脚本退出码。
物理备份（XtraBackup）要逐文件校验，不能只校顶层目录
全量物理备份是一堆文件：ibdata1、xtrabackup_checkpoints、一堆.ibd，缺一个整个恢复就崩。不能tar打包后再算一个MD5。正确做法是：
find /path/to/backup -type f -not -name "*tmp*" -not -name "xtrabackup_logfile" -exec md5sum {} \; > backup.md5。验证时同样用md5sum -c backup.md5。注意：innodb_page_size不同会导致.ibd文件结构不同，MD5天然不一致——校验前确认源和目标环境配置一致。
mysqldump参数会影响MD5稳定性，生产环境别乱开--skip-extended-insert
默认mysqldump用INSERT INTO t VALUES (),(),()批量插入，格式稳定，相同数据必然生成相同MD5。一旦加--skip-extended-insert，变成每行一个INSERT，换行、空格、字段顺序稍有差异就哈希不同。还有几个隐性影响点：
-
mysqldump版本不同，输出注释、时间戳、字符集声明可能变 -
--default-character-set没显式指定，依赖客户端默认值，跨机器容易不一致 - 备份时MySQL服务端
collation设置变了，排序规则影响ORDER BY结果，导出顺序不同，MD5就不同
mysql命令能跑完，但某张订单表少了一半记录。这种问题只能靠定期恢复测试暴露，而MD5是第一道也是最廉价的防线——它拦不住所有问题，但拦不住它，后面全是徒劳。 
