mysqldump 本身不支持配置默认备份路径，需通过绝对路径重定向输出，并确保目录存在且有写权限；my.cnf 仅用于认证简化，不可设备份路径；需自动清理旧备份并注意恢复时的字符集与建库问题。
mysqldump 备份时指定输出路径的关键点
直接用 mysqldump 命令本身不支持“配置默认备份路径”，它只负责生成 SQL 内容，写入哪里由 shell 重定向或脚本控制。所以所谓“配置路径”，实际是控制命令执行时的当前工作目录或显式指定文件名全路径。
常见错误：在 crontab 里写 mysqldump -u root db1 > backup.sql，结果发现文件总出现在 /root 或 cron 的默认工作目录（通常是 /），而非预期的 /backup。
- 务必使用绝对路径写入：
mysqldump -u root db1 > /backup/db1_$(date +\%F).sql - 确保目标目录存在且 mysqldump 执行用户（如 root 或 backup 用户）有写权限：
mkdir -p /backup && chown backup:backup /backup - 避免依赖
cd /backup && mysqldump ... > file.sql这种方式——crontab 默认不读取 shell 配置，cd可能无效
my.cnf 里不能设备份路径，但可以简化认证
my.cnf（通常在 /etc/my.cnf 或 ~/.my.cnf）不提供任何备份路径配置项。它的作用是避免在命令行硬写密码或重复指定 host/port —— 这对自动化脚本的安全性和可维护性很关键。
示例安全写法（~/.my.cnf，权限必须设为 600）：
[client] host = localhost user = backup_user password = "xxx" socket = /var/run/mysqld/mysqld.sock
这样调用时只需：mysqldump db1 > /backup/db1.sql，不用再加 -u -p -S 等参数。
- 切勿把密码写在 crontab 或 shell 脚本命令行里，会被
ps aux看到 -
backup_user应仅授予SELECT, LOCK TABLES, SHOW VIEW, TRIGGER权限，禁止GRANT或DROP - 如果 MySQL 启用了
skip_name_resolve，host必须写localhost（走 socket）或127.0.0.1（走 TCP），二者权限记录不同
自动清理旧备份：别只备份不删，磁盘迟早爆
备份文件堆着不清理，比不备份还危险。Linux 自带 find 就够用，无需额外工具。
- 保留最近 7 天的备份：
find /backup -name "*.sql" -type f -mtime +7 -delete - 更稳妥的做法是先
-print确认，再执行-delete - 注意
-mtime +7表示“修改时间大于 7×24 小时”，不是按日历天数；若每天固定时间运行，基本等价于“超过 7 天的文件” - 建议和备份命令写在同一脚本里，但放在
mysqldump成功之后（可用&&连接）
恢复时路径无关，但要注意字符集与模式
恢复操作（mysql 命令）不关心备份文件在哪，只关心能否读取。真正容易出问题的是隐含假设：
- 备份时没加
--default-character-set=utf8mb4，而库/表实际是 utf8mb4，恢复后中文变问号 - 备份未包含
CREATE DATABASE语句（默认不加--databases），恢复前要手动建库 - 用
source在 MySQL 客户端里导入大文件，可能因超时或内存不足中断；应优先用mysql db_name - 生产恢复前，务必先在测试库验证：
head -n 50 backup.sql看开头是否有SET NAMES、CREATE TABLE等关键语句
路径本身从来不是恢复失败的原因，但路径管理混乱会导致你根本找不到上一次成功的备份文件。
