mysql_config_editor是最简单有效的明文密码替代方案，它将加密凭据存于~/.mylogin.cnf并支持--login-path参数，但需注意cron环境路径、host匹配及账号最小权限限制。
直接用 mysql_config_editor 替换脚本里的 -p'xxx'，是最简单、最有效、且官方原生支持的解法。
为什么明文密码在备份命令里等于裸奔
只要命令行出现 -p'xxx' 或 --password=xxx，密码就会出现在：ps aux 输出里、shell history 里、系统审计日志（如 /var/log/audit/），甚至被容器运行时或 APM 工具捕获。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只对当前命令有效，不能“一次设置，全系统生效”
mysql_config_editor 不解决所有问题，得配合最小权限账号
它只是让密码不裸露，不代表账号本身够安全。如果 backup_user 拥有 DELETE 或 DROP 权限，被恶意调用 mysql --login-path=backup -e "DROP DATABASE" 照样出事。
所以必须限制账号权限：
- 只授
SELECT、LOCK TABLES、SHOW VIEW（如果导视图）、TRIGGER（如果导触发器） - 明确限定
GRANT ... ON database_name.*，别用ON *.* - 备份文件权限也要收紧：
chmod 600 /path/to/backup.sql，避免同服务器其他用户读取
真正麻烦的从来不是设置 login-path 这一步，而是确保 backup_user 的权限粒度刚好卡在「能 dump，不能删」的边界上——这个边界，得靠 SHOW GRANTS FOR 'backup_user'@'localhost' 一行行核对。
