mysql_config_editor是最简单有效的防密码泄露手段，它将凭据加密存入~/.mylogin.cnf并自动识别--login-path参数，避免明文密码出现在ps、history等位置。
直接用 mysql_config_editor 替代脚本里写 -p'xxx'，是目前最简单、最有效、且官方原生支持的防泄露手段。
为什么明文密码在备份脚本里等于裸奔
只要命令行里出现 -p'xxx' 或 --password=xxx，密码就会出现在：ps aux 输出里、shell history 里、系统日志（如 /var/log/audit/）中，甚至可能被容器或监控工具捕获。MySQL 官方文档明确将这种写法标记为「不安全」。
常见错误现象：
-
mysqldump -u backup -p'secret123' db被 cron 执行后，运维同事执行ps aux | grep mysqldump就能看到完整密码 - 脚本调试时加了
set -x，所有参数（含密码）全量打印到日志 - 备份失败报错信息里带出
Access denied for user 'backup'@'localhost' (using password: YES)，间接确认密码存在且被尝试
怎么用 mysql_config_editor 创建 login-path
它把凭据加密（实为混淆）存进 ~/.mylogin.cnf，权限自动设为 600，只有当前用户可读；后续所有 MySQL 客户端工具都能自动识别 --login-path 参数。
实操建议：
- 运行
mysql_config_editor set --login-path=backup --user=backup_user --host=localhost --password，回车后交互输入密码（不回显、不进 history） -
--login-path名字可自定义，比如prod、staging，方便多环境隔离 - 验证是否生效：
mysqldump --login-path=backup --no-defaults database_name | head -n5，能输出就说明连通 - 查看配置内容（不含密码）：
mysql_config_editor print --login-path=backup - 删错重来：
mysql_config_editor remove --login-path=backup
备份脚本里怎么替换？注意这 3 个坑
不是改一个参数就完事——--login-path 行为和传统 -u/-p 不完全等价，容易踩空。
常见错误现象：
- 脚本在 cron 里跑失败，但手动执行正常 → cron 默认没加载用户 shell 环境，
~可能解析成/root；务必用绝对路径调用，或在 crontab 中加HOME=/home/youruser -
mysqldump --login-path=backup db | gzip > /backup/db.sql.gz报错Access denied→ 检查mysql_config_editor print --login-path=backup输出的host是否和权限表匹配（localhost≠127.0.0.1） - 误以为设置一次就全局生效 →
--login-path只对当前命令有效，每个mysqldump、mysqladmin、mysqlbinlog都得显式带上
它不能解决什么？必须配合的底线措施
mysql_config_editor 只解决「密码不以明文形式暴露在进程参数或脚本中」这一层，不是银弹。
关键限制：
- 生成的
~/.mylogin.cnf是混淆而非强加密，换同名用户即可读取，**绝不能放在生产数据库服务器上**（只应在备份机、CI 机等可信终端使用） - 账号本身权限必须最小化：
backup_user只应有SELECT、LOCK TABLES、SHOW VIEW，禁用DROP、DELETE、GRANT OPTION - 文件落地后仍需防护：备份生成的
.sql文件必须立刻chmod 600，目录设为700，且不能放在 Web 可访问路径下
真正安全的备份链路，是 login-path + 最小权限账号 + 严格文件权限 + 内容加密（如 gpg）四者缺一不可；其中最容易被跳过的，就是账号权限控制和备份文件落盘后的 chmod 操作。
