必须在备份完成的同一台机器、同一时刻立即计算并保存md5sum校验值，且恢复前须用md5sum -c严格验证；错误做法包括传输后校验、仅人工查看结果、忽略退出码检查。
备份后立刻计算 md5sum 并保存校验值
只备份不校验，等于没备份。MySQL 自身不提供备份文件完整性校验机制，必须在备份完成的同一台机器、同一时刻，用 md5sum 算出哈希值并落盘保存。
- 错误做法：把备份文件拷到另一台机器再算 md5 —— 传输过程可能出错，校验失去意义
- 正确顺序：
mysqldump或mysqlpump完成 → 立即执行md5sum backup.sql > backup.sql.md5 - 务必保存
.md5文件和备份文件在同一目录，且命名严格对应（如prod_20240615.sql和prod_20240615.sql.md5） - 别用
md5命令单独打屏看结果——人眼比对不可靠，必须写入文件供后续自动校验
恢复前必须验证 md5sum -c 校验失败会中断导入
很多人以为“文件能打开就能恢复”，但损坏的 SQL 文件可能前半段语法合法，导入中途报错，导致数据不全且难以回溯。校验必须在 mysql 命令执行前完成。
- 执行
md5sum -c backup.sql.md5，输出backup.sql: OK才可继续 - 若输出
backup.sql: FAILED，立即停止，检查文件是否被截断、磁盘是否只读、或 NFS 挂载异常 - 注意：
md5sum -c默认读取当前目录下的.md5文件，路径不匹配会直接报md5sum: backup.sql.md5: no properly formatted MD5 checksum lines found - 不要跳过这步去“试试看”——部分损坏的 dump 文件会成功建表但漏掉某些 INSERT，问题暴露在业务侧，代价远高于停顿几秒校验
mysqldump 加 --skip-extended-insert 会影响 md5 稳定性
默认 mysqldump 把多行 INSERT 合并为一条（INSERT INTO t VALUES (...),(...),(...)），这个格式对 md5 更友好；但开启 --skip-extended-insert 后，每行一个 INSERT，换行符和空格稍有差异就导致哈希值不同。
- 如果你需要人工阅读或 diff 备份内容，可以开这个参数，但必须清楚：同一库两次备份即使数据完全一致，md5 也可能不同
- 生产环境建议关闭该参数（即使用默认 extended-insert），保证相同数据产生相同 md5
- 如果已启用该参数，校验前需确认两次备份是否使用完全相同的 mysqldump 版本、字符集、排序规则，否则 md5 对不上不是文件损坏，而是输出不稳定
大文件下 md5sum 性能低？改用 sha256sum 并不解决问题
有人听说 SHA256 比 MD5 “更安全”，就换成 sha256sum，其实对完整性校验场景无实质提升，反而拖慢速度。
- MD5 在纯完整性校验中依然可靠——攻击者篡改备份文件不是威胁模型，我们防的是磁盘坏道、传输丢包、误删截断
-
sha256sum计算耗时通常是md5sum的 3–5 倍，百 GB 级备份可能多等几分钟，没必要 - 真正影响性能的是 I/O：确保备份盘不是高负载的机械盘或共享云盘；可考虑用
pv+md5sum流式计算，避免先写满再校验 - 别为了“看起来更高级”换算法——脚本里写死
md5sum，团队成员都熟悉，出问题能快速定位
最常被忽略的一点：备份脚本里写了 md5sum，但没检查它的退出码。哪怕校验失败，脚本仍继续执行恢复逻辑。务必用 if ! md5sum -c backup.sql.md5; then exit 1; fi 这类显式判断，否则校验形同虚设。
