备份文件末尾截断会导致恢复卡顿或报ERROR 1064，需用tail -n 20检查UNLOCK TABLES;等完整结尾标志；md5sum必须与mysqldump串行执行（&&连接），且仅当md5sum -c输出“backup.sql: OK”才视为校验通过；导入前应先在隔离环境验证DDL执行成功及数据一致性。
备份文件末尾是否截断
文件看似存在，但实际写入中途失败，会导致恢复时卡在中间或报 ERROR 1064 (42000)。mysqldump 静默退出不代表内容完整。
实操建议：
- 用
tail -n 20 backup.sql看结尾是否有完整的UNLOCK TABLES;和分号（;） - 检查是否以
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;类语句收尾——这是 mysqldump 正常结束的标志之一 - 若结尾是乱码、空行或突然中断（比如最后几行全是
INSERT INTO ... VALUES (...没闭合），基本可判定截断
md5sum 必须和备份命令串行执行
延迟哪怕 2 秒再跑 md5sum，就可能校验到未刷盘的缓存数据，导致哈希值与真实文件不一致。
实操建议：
- 强制用
&&连写：mysqldump -u root db > backup.sql && md5sum backup.sql > backup.sql.md5 -
.md5文件必须和backup.sql同目录，且权限设为700，不能和备份文件共用同一块物理磁盘 - 恢复前只认
md5sum -c backup.sql.md5输出中的backup.sql: OK—— 其他任何输出都算失败，别跳过这步直接导入
语法层面能否被 mysql 客户端解析
字符集声明错、CREATE VIEW 依赖缺失、--skip-extended-insert 导致单行超长，都会让 mysql 在导入时直接报错退出。
实操建议：
- 新建空库：
mysql -e "CREATE DATABASE restore_test DEFAULT CHARSET = utf8mb4;" - 只导入 DDL（建表语句）：
grep -E "^(CREATE TABLE|USE )" backup.sql | mysql restore_test - 检查返回值：
echo $?必须是0；若出现ERROR 1146，说明CREATE TABLE没成功执行，得回溯 dump 参数是否漏了--routines或--triggers - 对压缩包先解压再验证：
zcat backup.sql.gz | head -n 100 | mysql -D test_dummy -e "SELECT 1;" 2>&1 | grep -i error
隔离环境里能否还原出一致数据
语法通 ≠ 数据可用。外键顺序错、GTID 不匹配、时区差异导致 DATETIME 偏移、JSON 字段在旧版 MySQL 解析失败，这些都只会在真实还原后暴露。
实操建议：
- 用 Docker 起一个和生产同版本的 MySQL 实例：
docker run -d --name mysql-test -e MYSQL_ROOT_PASSWORD=123 -p 3307:3306 mysql:8.0 - 导入时禁用外键检查：
mysql -h127.0.0.1 -P3307 -u root -p123 --init-command="SET SESSION FOREIGN_KEY_CHECKS=0;" db_name - 还原后立刻比对：
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name';和源库是否一致 - 大表抽样校验：
SELECT COUNT(*), MD5(GROUP_CONCAT(CONCAT_WS('|', col1, col2))) FROM table_name;—— 这个组合值在源库和恢复库必须完全相同
md5sum -c 的返回值必须参与脚本判断，而不是只看终端输出；还有 backup.sql.md5 文件本身也得定期用 sha256sum 单独保护——它被篡改，整个校验链就失效了。 
