mysqldump导出必须通过管道配合gzip压缩，不可直接压缩；需注意密码格式、避免锁表、指定字符集、环境变量配置、文件名去重、完整性校验及智能清理策略。
mysqldump 导出时不能直接压缩，得靠管道配合 gzip
MySQL 自身不提供导出即压缩的选项，mysqldump 输出的是纯 SQL 文本流，想压缩必须用 shell 管道接 gzip。硬写成两步（先 dump 再 gzip）不仅多占磁盘空间，还增加失败风险——比如中间磁盘满，就卡在半路。
实操建议：
- 用
mysqldump -u user -p'pass' db_name | gzip > backup_$(date +\%Y\%m\%d).sql.gz一行搞定 - 务必加
-p'pass'（密码紧贴-p，无空格），否则脚本会交互等待输入，导致定时任务卡死 - 导出大库时加
--single-transaction（InnoDB）或--lock-tables=false（谨慎用），避免锁表阻塞业务 - 别省略
--default-character-set=utf8mb4，否则中文可能乱码，恢复时更难排查
crontab 定时执行前必须测试环境变量和路径
crontab 默认 PATH 很窄，常找不到 mysqldump 或 gzip，报错类似 /bin/sh: mysqldump: not found。这不是权限问题，是环境变量缺失。
实操建议：
- 在脚本开头显式声明 PATH：
PATH=/usr/local/bin:/usr/bin:/bin - 用
which mysqldump和which gzip确认实际路径，脚本里写绝对路径更稳，比如/usr/bin/mysqldump - 测试 cron 前先手动用
env -i /bin/sh模拟最小环境运行脚本，看是否报错 - 重定向 stderr 到日志：
2>> /var/log/mysql_backup.log，不然失败了也看不到错误
备份文件名带日期但容易覆盖，得加时间戳或校验逻辑
只用 $(date +\%Y\%m\%d) 一天只能存一个备份，如果脚本意外重复执行，后一次直接覆盖前一次。线上出事回溯时发现“昨天的备份其实是下午3点的”，就很被动。
实操建议：
- 改用
$(date +\%Y\%m\%d_\%H\%M)，精确到分钟，避免覆盖 - 加简单存在性检查：
if [ -f "$backup_file" ]; then echo "Backup exists, skip"; exit 1; fi - 导出完成后用
gzip -t "$backup_file"验证压缩包完整性，损坏的 gzip 文件解压时才暴露，太晚 - 大库建议加
du -h "$backup_file"日志，突然变小可能意味着导出被中断
自动清理旧备份不能只看文件数，得结合保留天数和磁盘水位
用 find /path -name "*.sql.gz" -mtime +7 -delete 看似合理，但遇到磁盘突然吃紧（比如日志暴涨），等 find 触发时可能已经没空间跑下一次备份了。
实操建议：
- 清理前先查剩余空间：
df -h /backup | awk 'NR==2 {print $5}' | sed 's/%//'，超 90% 就强制删最老的 3 个 - 保留策略分层：最近 3 天每天 1 份，上周每天 1 份，再往前每月 1 号存 1 份（需额外逻辑判断日期）
- 删除命令加
-v参数并记录日志，避免误删后无迹可寻 - 别用
rm -rf直接删整个目录，find加-maxdepth 1限定只删当前层文件
真正麻烦的不是写对一行 mysqldump | gzip，而是让这套逻辑在磁盘告警、MySQL 临时不可达、cron 环境缺失时还能留下线索、不静默失败。每次改完脚本，记得手动删掉一个现有备份，看它会不会自动补上——这才是最接近真实的测试。
