MySQL备份失败需检查权限、存储空间、连接状态和SQL语法四类问题：确认备份用户具备SELECT、LOCK TABLES、RELOAD权限；检查磁盘空间与写入权限；延长connect-timeout等超时参数；校验SQL模式与字符集兼容性。
MySQL备份失败需要快速定位原因并恢复备份流程，核心是检查权限、存储空间、连接状态和SQL语法四类常见问题。
检查MySQL用户备份权限是否充足
mysqldump等工具需要SELECT、LOCK TABLES、RELOAD（含FLUSH TABLES）等权限。仅授予USAGE权限会导致静默失败。
- 登录MySQL执行：SHOW GRANTS FOR 'backup_user'@'host';
- 若缺少必要权限，用root执行：GRANT SELECT, LOCK TABLES, RELOAD ON *.* TO 'backup_user'@'host'; FLUSH PRIVILEGES;
- 注意：远程备份需确认用户host匹配，如'backup_user'@'%'而非'backup_user'@'localhost'
确认磁盘空间与文件写入权限
备份文件写入失败常表现为“Permission denied”或“No space left on device”，但错误日志可能只显示“command exited with code 2”。
- 运行df -h /backup/path检查目标分区剩余空间（建议预留≥备份预估大小的1.5倍）
- 执行touch /backup/path/test_file && rm /backup/path/test_file验证写入权限
- 若使用管道压缩（如mysqldump | gzip），注意/tmp或/proc/sys/kernel/msgmax等临时资源限制
排查连接超时与网络中断
长表导出或慢查询场景下，wait_timeout、connect_timeout设置过短易导致中途断连，报错类似“MySQL server has gone away”。
- 在备份命令中显式延长超时：mysqldump --connect-timeout=300 --net-read-timeout=3600 --net-write-timeout=3600 ...
- 服务端同步调整：SET GLOBAL wait_timeout = 28800;（需SUPER权限，重启失效）
- 对主从架构，避免在主库高负载时段执行全库dump，可改用从库备份
验证SQL模式与字符集兼容性
启用STRICT_TRANS_TABLES或NO_ZERO_DATE等严格模式时，某些历史数据可能触发dump中断；字符集不一致则导致乱码或截断。
- 备份前添加参数：--skip-extended-insert --default-character-set=utf8mb4
- 检查当前会话SQL模式：SELECT @@sql_mode;，临时放宽可加--set-gtid-purged=OFF --skip-triggers排除干扰
- 导入验证时用mysql --default-character-set=utf8mb4 ... 确保编码一致
不复杂但容易忽略。每次备份脚本上线前，在测试环境模拟磁盘满、kill -9 mysqldump进程、切换低权限用户等异常，能提前暴露多数隐患。
