必须在mysqldump完成后立即执行md5sum生成校验值并保存为同名.md5文件，恢复前用md5sum -c严格验证，仅显示“backup.sql: ok”才可导入，否则可能因截断、坏道或缓存异常导致中途失败。
备份完成后立刻计算并保存 md5sum 校验值
只生成备份文件不校验，等于没备份。MySQL 自身不提供任何内置完整性校验机制，必须在 mysqldump 或 mysqlpump 命令执行完毕的同一台机器、同一时刻，立即运行 md5sum 计算哈希值，并写入对应 .md5 文件。
- 正确做法：
mysqldump -u root -p mydb > prod_20260702.sql && md5sum prod_20260702.sql > prod_20260702.sql.md5 - 错误做法：把
.sql文件拷到另一台机器再算md5sum—— 传输过程可能引入静默损坏，校验失去意义 - 命名必须严格对应：若备份文件是
app_20260702.sql，校验文件就得叫app_20260702.sql.md5，否则md5sum -c找不到目标
恢复前必须用 md5sum -c 严格验证
很多人跳过这步直接执行 mysql 导入，结果遇到半截损坏的 SQL 文件：建表成功、前几万行 INSERT 成功，中间某处语法错或截断，导致数据不全且无报错提示——问题暴露在业务侧，代价远高于多等 2 秒校验。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 执行
md5sum -c app_20260702.sql.md5，只有输出app_20260702.sql: OK才能继续导入 - 若输出
FAILED，常见原因包括：文件被截断（du -h对比原始大小）、磁盘只读、NFS 挂载异常、或备份时mysqldump进程被 kill -
md5sum -c默认只读当前目录下的.md5文件；路径不匹配会报错md5sum: app_20260702.sql.md5: no properly formatted MD5 checksum lines found
mysqldump 参数影响 md5 稳定性
相同数据库、相同命令，两次导出的 SQL 文件 MD5 不一致，未必是文件损坏，很可能是参数或环境差异导致输出不稳定。
- 避免使用
--skip-extended-insert：它让每行一个INSERT，换行符和空格微小变化就会改变哈希值；生产环境建议用默认的 extended-insert 格式 - 确保
mysqldump版本一致：不同版本对注释、时间戳、字符集声明的处理可能不同 - 统一字符集与排序规则：导出时显式指定
--default-character-set=utf8mb4和--collation-server=utf8mb4_0900_ai_ci，避免因服务器配置漂移导致差异
别为了“更安全”换成 sha256sum
MD5 在备份完整性校验场景中依然可靠——我们防的是磁盘坏道、传输丢包、误删截断，不是对抗恶意篡改。换成 sha256sum 只会拖慢速度，毫无收益。
-
sha256sum计算耗时通常是md5sum的 3–5 倍，百 GB 级备份可能多等几分钟 - 真正瓶颈是磁盘 I/O，不是哈希算法本身；优化方向应是使用更快的存储介质或并发压缩，而非换算法
- 只要校验流程闭环（备份即算、恢复前必验、自动检查退出码），MD5 完全够用
