mysqldump仅读取[client]和[mysqldump]段配置，密码须明文写在[client]段且文件权限为600；crontab中需用绝对路径指定--defaults-file，并避免--no-defaults或--defaults-extra-file引发静默失效。
mysqlbackup 命令不读取 my.cnf 的默认行为
直接执行 mysqldump 时，它默认会读取 my.cnf（或 my.ini）里的 [client] 段配置，但很多人误以为所有参数都会自动生效——其实不是。比如 password 字段如果明文写在 [client] 里，mysqldump 会用，但若写在 [mysqld] 段，就完全无效；更关键的是，某些系统级备份脚本调用 mysqldump 时加了 --defaults-file，反而会跳过全局配置文件。
-
mysqldump只认[client]和[mysqldump]段，[mysqld]段对它没用 - 使用
--defaults-file=/path/to/my.cnf会强制只读该文件，忽略/etc/my.cnf、~/.my.cnf等其他位置 - 密码字段必须写成
password = your_pass（注意等号两边可有空格），不能是password="xxx"或password: xxx - 如果配置文件权限太宽松（如 group/other 可读），
mysqldump会直接报错退出，并提示File '/path/to/my.cnf' mode is too open
如何安全地把账号密码放进选项文件
硬编码密码到 shell 脚本里是高危操作，而选项文件能规避命令行历史泄露、ps 进程可见等问题，但前提是文件权限和写法都正确。
- 创建专用配置文件，比如
~/.mybackup.cnf，内容只包含：[client] host = localhost user = backup_user password = S3cureP@ss2024 port = 3306
- 立刻执行
chmod 600 ~/.mybackup.cnf，否则mysqldump拒绝读取 - 不要在
[client]段以外的地方写密码，[mysqldump]段可以复写参数（如single-transaction），但密码必须在[client] - 测试是否生效：运行
mysqldump --defaults-file=~/.mybackup.cnf --no-defaults -n -t mysql user | head -3，能输出即表示连接成功
crontab 自动备份时的路径与环境陷阱
很多定时任务失败，不是 SQL 逻辑问题，而是 mysqldump 根本找不到配置文件，或当前环境变量导致路径解析异常。
- crontab 默认
$HOME是 root（即使你编辑的是用户 crontab），所以~/.mybackup.cnf在 root 环境下指向的是/root/.mybackup.cnf，不是你的家目录 - 务必在 crontab 条目中写绝对路径：
0 2 * * * /usr/bin/mysqldump --defaults-file=/home/backup/.mybackup.cnf --databases appdb > /backup/appdb_$(date +\%F).sql - 避免在命令中用
~或$HOME，cron 不一定加载 shell profile，$PATH也很窄，优先用/usr/bin/mysqldump而非mysqldump - 加
--no-defaults是危险操作——它会禁用所有配置文件，包括你刚写的那个，除非你明确想绕过所有配置
备份脚本里要不要加 --defaults-extra-file？
这个参数常被推荐用来“追加”配置，但它其实是个误导性很强的开关：它不是“额外读一个”，而是“替换默认搜索链”，容易引发静默失效。
-
--defaults-extra-file的行为是：先读该文件，再读[client]段（如果存在），但跳过所有其他默认位置（如/etc/my.cnf） - 如果你只想覆盖密码，又不想动全局配置，直接用
--defaults-file更干净；--defaults-extra-file适合临时注入一组调试参数，不适合生产备份 - 真正需要多环境切换时，建议用不同配置文件 + 显式
--defaults-file，而不是依赖顺序叠加 - 注意：该参数值必须是绝对路径，相对路径在 cron 下大概率失败
配置文件本身不复杂，难的是每层调用链上权限、路径、段名、环境变量四个点同时对齐。少一个，备份就静默失败，日志里还看不出原因。
