生产环境 mysql 备份必须使用 --single-transaction --routines --triggers --events，配合 ~/.my.cnf 凭据、flock 加锁、绝对路径调用、utc 时间命名、aws s3 cp 或 rclone 上传及上传成功后 find -delete 清理。
mysqldump 备份命令必须加 --single-transaction 和 --routines
不加 --single-transaction，InnoDB 表备份时可能被写入阻塞，或产生不一致快照；跳过 --routines 会导致存储过程、函数丢失，恢复后业务逻辑直接报错。
常见错误现象：mysqldump: Got error: 1146: Table 'mysql.proc' doesn't exist（旧版 MySQL 用 --routines，新版用 --routines --triggers）
- 生产环境务必加上
--single-transaction --routines --triggers --events - 避免用
-p密码（明文暴露在进程列表），改用配置文件~/.my.cnf并设权限chmod 600 ~/.my.cnf - 导出时加
--skip-lock-tables（--single-transaction已隐含，但显式写上更安全） - 压缩建议用
gzip -3（平衡速度与压缩率），别用-9，备份窗口长、CPU 占用高
用 aws s3 cp 或 rclone sync 传到云存储，别用 curl 上传
curl 上传大文件易中断、无重试、没进度反馈；aws s3 cp 自带分块上传、断点续传、自动重试和 MD5 校验。
使用场景：阿里云 OSS、腾讯云 COS 也推荐用 rclone，统一配置、支持加密、可增量同步
aws s3 cp backup.sql.gz s3://my-bucket/mysql/$(date +\%Y\%m\%d_\%H\%M\%S).sql.gzrclone copy --transfers=2 --checkers=2 --retries=3 backup.sql.gz remote:backups/mysql/- 上传前先
test -f backup.sql.gz && [ $(stat -c "%s" backup.sql.gz) -gt 1000 ]，防空文件误传 - 别把密钥硬编码进脚本，用
aws configure或rclone config预置凭据
crontab 定时执行要处理环境变量和路径问题
crontab 默认 PATH=/usr/bin:/bin，找不到 mysqldump 或 aws，也不读 ~/.bashrc，导致脚本本地能跑、定时就失败。
常见错误现象：/bin/sh: mysqldump: not found 或 Command 'aws' not found
- 在 crontab 里写全路径：
/usr/bin/mysqldump、/usr/local/bin/aws（用which mysqldump确认） - 在脚本开头加
source /etc/profile; source ~/.bash_profile不可靠，直接导出变量更稳：export PATH="/usr/local/bin:/usr/bin:/bin" - 用绝对路径写日志：
> /var/log/mysql-backup.log 2>&1，别用~/log - 加锁防止并发：用
flock -n /tmp/mysql-backup.lock -c "..."，避免上一次没跑完下次又启动
备份保留策略靠 find 删除旧文件，别依赖云存储生命周期规则
云厂商的生命周期规则延迟高、不可见、难调试；本地先删再上传，可控性强，还能留个“最后删除日志”。
性能影响：find /backup -name "*.sql.gz" -mtime +7 -delete 在百万小文件目录下会卡，但 MySQL 备份通常每天 1–10 个文件，没问题
- 删除命令放上传成功之后：
if [ $? -eq 0 ]; then find /backup -name "mysql_*.sql.gz" -mtime +7 -delete; fi - 别用
-exec rm {} \;，慢且信号不敏感；-delete更快更安全 - 保留命名规范：文件名含日期时间，如
mysql_20240520_230000.sql.gz，方便find筛选 - 上传失败时，旧备份不能删——所以删除动作必须严格绑定上传成功状态
真正麻烦的是跨时区服务器+异地云存储+不同压缩格式混合的情况，这时候文件名里的时间戳必须统一用 UTC，否则 find -mtime 会算错天数。
