备份后必须立即生成md5校验值，否则无法发现磁盘坏道、nfs缓存异常等导致的文件截断或错位；需用&&串行执行mysqldump与md5sum，确保同一时刻同路径生成并保存校验值，且恢复前必须用md5sum -c严格验证。
备份后不立刻算 md5sum，等于没备份。 MySQL 自身不校验文件内容，只管把数据写进磁盘；而磁盘坏道、NFS 缓存异常、写入中断这些情况，都会让 backup.sql 看似存在、实则截断或错位。唯一能暴露这类问题的，就是哈希值——但必须在备份完成的同一时刻、同一路径下生成并保存。
mysqldump 完成后 1 秒内必须执行 md5sum
不能靠人工想起来再跑，也不能等定时任务触发。延迟哪怕 3 秒，就可能错过写入未刷盘、文件句柄未关闭的窗口，导致校验的是“半成品”。
- 用
&&强制串行：mysqldump -u root db > backup_$(date +%F).sql && md5sum backup_$(date +%F).sql > /backup/checksums/backup_$(date +%F).sql.md5 - 确保
/backup/checksums/是独立目录，权限设为700，且不和备份文件同盘（避免整盘故障时一起丢） - 别用
md5sum backup.sql打屏看结果——人眼比对不可靠，也留不下可自动验证的记录
恢复前必须用 md5sum -c 严格验证
很多人跳过这步直接 mysql -u user db ，结果导入到一半报语法错误，才发现文件末尾是乱码或空行。这时已建表、部分数据入库，回滚成本远高于提前几秒校验。
- 运行前先
cd /backup/checksums，再执行md5sum -c backup_2026-05-09.sql.md5 - 输出必须含
backup_2026-05-09.sql: OK才能继续；若显示FAILED，立即停手，查df -h是否磁盘满、dmesg | tail是否有 I/O 错误 - 注意：
.md5文件里写的是相对路径名（如backup_2026-05-09.sql），当前目录必须能访问到该文件，否则加--strict并用绝对路径
--skip-extended-insert 会让两次备份的 md5 必然不同
这个参数让 mysqldump 每行只写一个 INSERT，方便人工阅读或 diff，但换行符、空格、字段顺序等微小差异都会改变哈希值。它破坏的是“相同数据 → 相同哈希”的确定性。
- 生产环境建议关闭该参数（即使用默认的 extended-insert），保证同一库两次全量备份，只要数据一致，
md5sum就一致 - 如果已启用，校验时必须确认：两次备份用的是完全相同的
mysqldump版本、字符集（--default-character-set=utf8mb4）、排序规则（--collation-server=utf8mb4_0900_ai_ci） - 别为了“看起来整齐”牺牲可验证性——完整性比可读性优先级高得多
真正难控的不是命令怎么写，而是校验动作和备份动作之间的时间耦合度。你得确保 mysqldump 进程退出后，md5sum 立刻开始读那个文件，中间不能有 shell 调度延迟、IO 队列堆积或 NFS 缓存干扰。这点在大库（>50GB）或低配机器上尤其明显。
