推荐关键参数组合：--single-transaction（保障innodb一致性）、--routines --events --triggers（导出逻辑对象）、--default-character-set=utf8mb4（防乱码）、--hex-blob（安全处理blob）；密码须通过~/.my.cnf配置，文件权限设为600。
MySQL备份命令 mysqldump 的关键参数怎么选
直接用 mysqldump 备份，不加参数容易出问题：比如没加 --single-transaction，高并发写入时可能导出不一致数据；漏掉 --routines 或 --events，存储过程和事件就丢了；没指定 --default-character-set=utf8mb4，中文可能乱码。
推荐基础组合：
-
--single-transaction：对 InnoDB 表保证一致性快照（MyISAM 不适用，需配合--lock-all-tables） -
--routines --events --triggers：一并导出函数、存储过程、事件、触发器 -
--default-character-set=utf8mb4：避免字符集降级导致的乱码 -
--hex-blob：安全导出 BLOB 字段（如图片路径、JSON 二进制内容）
Shell 脚本里如何安全拼接文件名和路径
备份文件名带日期是刚需，但直接用 $(date +%Y%m%d) 在脚本中容易因空格或特殊字符崩掉；更糟的是把密码写死在命令行里，ps aux 能直接看到——这属于严重安全隐患。
正确做法：
- 用
$(date +\%Y\%m\%d_\%H\%M)（反斜杠转义 %，防止 shell 解析错误） - 密码绝不出现于
mysqldump命令行，改用 MySQL 配置文件：~/.my.cnf，权限设为600 - 路径统一用变量定义，例如
BACKUP_DIR="/data/backup/mysql"，后续用"${BACKUP_DIR}/db_${DATE}.sql.gz" - 执行前检查目录是否存在：
mkdir -p "${BACKUP_DIR}"
Crontab 定时执行时权限和环境变量为什么总不对
手动运行脚本能成功，放进 crontab -e 就失败，90% 是因为 cron 使用最小化环境：没有 $PATH，找不到 mysqldump 或 gzip；且默认以 root 或指定用户身份运行，但该用户可能没读取 ~/.my.cnf 的权限。
必须显式处理：
- 在 crontab 条目里写绝对路径：
/usr/bin/mysqldump而不是mysqldump - 在脚本开头加
source /etc/profile或显式设置 PATH：export PATH="/usr/local/bin:/usr/bin:/bin" - 用
crontab -u mysql -e切换到 MySQL 服务同用户，确保能读/var/lib/mysql/.my.cnf - 加日志重定向：
/path/to/backup.sh >> /var/log/mysql-backup.log 2>&1，否则失败无声无息
备份文件怎么自动清理又不误删
每天一个全量备份，不清理半年后磁盘就爆。但用 find /backup -name "*.sql.gz" -mtime +7 -delete 很危险：如果脚本某次没生成新文件，-mtime +7 可能把所有旧文件全干掉。
稳妥策略是按数量保留，而非时间：
- 用
ls -t "${BACKUP_DIR}"/db_*.sql.gz | tail -n +8 | xargs -r rm -f：保留最新 7 个 - 先
ls再tail再xargs -r（-r防止无匹配时报错） - 清理命令必须放在备份成功之后，加判断：
if [ $? -eq 0 ]; then ... fi - 别用
rm -rf直接删目录，只删明确匹配的压缩包
最易被忽略的是：mysqldump 出错时返回非零状态，但脚本里没检查，后续压缩、清理照常执行，结果留了个空的 .sql.gz 文件——看着有备份，其实恢复不了。
