MySQL 安装时无法直接配置备份与恢复路径
MySQL 本身不提供安装阶段设置「默认备份/恢复目录」的选项。
mysqld服务不管理备份路径，
mysqldump和
mysql命令也默认不读取配置文件中的「备份目录」字段——它们只接受显式指定的文件路径。
真正需要配置的是 mysqldump 和 mysql 的常用路径习惯
用户真正想解决的，是避免每次执行备份/恢复都要敲一长串绝对路径。这不是靠 MySQL 安装配置能搞定的，而是靠 Shell 环境或封装脚本控制：
mysqldump输出路径完全由
-r或重定向（
>）决定，例如：
mysqldump -u root -p mydb > /backup/mydb_$(date +%F).sql
mysql恢复时，SQL 文件路径必须明确给出：
mysql -u root -p mydb < /backup/mydb_2024-06-15.sql可把常用路径设为变量，写进
~/.bashrc：
export MYSQL_BACKUP_DIR="/backup"，之后用
$MYSQL_BACKUP_DIR引用 不要依赖
my.cnf中的
[mysqldump]段落设路径——它只支持
user、
password、
host等连接参数，不支持
output-path这类不存在的选项
自动备份脚本里最容易漏掉的三件事
很多用户写完脚本发现备份失败，问题常出在权限、路径和时间戳上：
运行脚本的用户（如mysql或
root）必须对
/backup目录有
wr权限，且该目录需提前创建：
sudo mkdir -p /backup && sudo chown mysql:mysql /backup用
date生成文件名时，避免冒号（
:）——Windows 或某些 NFS 挂载点不支持：
$(date +'%F_%H-%M-%S')是安全的，
$(date +'%T')会出错 备份前建议加
test -d /backup || exit 1，防止路径不存在导致静默失败 别把备份文件和 binlog 放同一磁盘分区——磁盘满会导致主库 hang 住
恢复时路径错误的典型报错和应对
执行
mysql恢复时路径不对，不会提示「找不到文件」，而是卡住或报错
ERROR 1049 (42000): Unknown database（如果 SQL 文件里含
USE xxx但数据库不存在），或更隐蔽的
ERROR 2013 (HY000)（连接中断，实际是文件读取失败）。 先用
ls -l /path/to/backup.sql确认文件存在且非空 用
head -n 5 /path/to/backup.sql看是否是合法 SQL（开头应有
-- MySQL dump或
CREATE DATABASE） 恢复命令中不要加引号包裹路径，除非含空格：
mysql -u root -p mydb 正确，<code> 不必要若 SQL 文件里没建库语句，要先手动
CREATE DATABASE mydb，再导入
路径本身不是 MySQL 的配置项，它是操作者对工具链的理解深度体现。最常被忽略的，其实是备份文件的归属用户和 SELinux 上下文（在 CentOS/RHEL 上，
restorecon -Rv /backup有时比 chmod 还关键）。
