crontab中mysqldump不执行的主因是环境变量缺失导致命令找不到，须用绝对路径、显式设置PATH、重定向stderr、明确工作目录；备份为空或卡住多因权限不足、锁表或连接问题，应授权SELECT+LOCK TABLES、加--single-transaction、用-h 127.0.0.1；命名需含时间戳并压缩，定期清理旧文件，检查磁盘空间；cron时间格式易错，须按“分 时 日 月 周”顺序配置，root任务用sudo crontab -e，并通过日志验证执行。
crontab 里 mysqldump 命令不执行，连错误都不报
常见现象是脚本手动运行正常，放进 crontab 就静默失败。根本原因是 cron 环境变量极简——PATH 不含 /usr/bin 或 /usr/local/mysql/bin，导致找不到 mysqldump。
实操建议：
- 所有命令用绝对路径：
/usr/bin/mysqldump、/bin/gzip、/usr/bin/find - 在脚本开头显式设置环境：
export PATH="/usr/bin:/bin:/usr/local/mysql/bin" - 重定向 stderr 到日志，否则错误全丢掉：
2>> /var/log/backup.log - 避免依赖当前工作目录，脚本里用
cd /backup明确路径
mysqldump 备份时卡住或导出为空
典型表现是生成的 .sql 文件只有几 KB，甚至为空；或者备份耗时远超预期。多半是权限、连接或锁的问题。
实操建议：
- 账号必须有
SELECT+LOCK TABLES权限（--single-transaction可绕过锁表，但仅对 InnoDB 有效） - 加
--single-transaction参数避免长事务阻塞，比--lock-tables更安全 - 排除网络因素：用
-h 127.0.0.1强制走 TCP，避免 Unix socket 权限问题 - 大库务必加
--compress减少传输压力，尤其远程备份时
备份文件命名混乱、磁盘被撑爆
不带时间戳的文件名（如 backup.sql）每次覆盖，丢了就真没了；不清理旧文件，三个月后 /backup 目录占满 100GB。
实操建议：
- 文件名必须含时间：
backup_$(date +\%Y\%m\%d_\%H\%M).sql - 压缩一步到位：
mysqldump ... | gzip > backup_$(date +\%Y\%m\%d).sql.gz - 自动清理 7 天前的备份：
find /backup -name "backup_*.sql.gz" -mtime +7 -delete - 备份前检查空间：
df /backup | awk 'NR==2 {print $5}' | sed 's/%//'，超 90% 就跳过并报警
crontab 时间格式写错，备份永远不触发
最常踩的坑是把 0 2 * * *（每天 2 点）误写成 2 0 * * *（每月 2 日 0 点），或者忘了 sudo crontab -e 和 crontab -e 权限不同。
实操建议：
- 用
sudo crontab -e编辑 root 的任务（因为备份需读取 MySQL 配置和写系统目录） - 时间字段顺序固定：
分 时 日 月 周，记不住就查man 5 crontab - 测试用
*/10 * * * *（每 10 分钟一次），确认能跑通再切回正式频率 - 修改后别忘验证：
sudo systemctl status cron确保服务活着，sudo tail -f /var/log/syslog | grep CRON看是否调度成功
真正麻烦的是跨时区服务器、MySQL 密码含特殊字符、以及 mysqldump 进程被 OOM killer 杀掉——这些不会报错，只留一个空文件。得靠日志+校验和+人工抽查兜底。
