mysql_config_editor存储的密码并非加密而是混淆，使用固定密钥和简单异或+移位处理，仅防明文泄露，不防逆向；适用于本地开发或CI等可信环境，不可用于生产服务器。
mysql_config_editor 存储的密码是加密的吗？
不是真正意义上的“加密”，而是混淆（obfuscation）。mysql_config_editor 把密码用固定密钥和简单异或+移位逻辑处理后存进 ~/.mylogin.cnf，不防逆向，只防明文泄露。它解决的是「配置文件里写明文密码」这个最基础的风险，不是替代权限管控或网络加密。
常见错误现象：mysql --login-path=prod 能连上，但有人直接 cat ~/.mylogin.cnf 后试图 hexdump + 猜解，结果真还原出了密码——这说明你误以为它用了强加密。
- 使用场景：仅限本地开发机、CI 机器等可信环境；生产数据库服务器上不应存在该文件
- 它不保护传输过程，也不影响主从复制本身的通信安全（那是 SSL/TLS 和
CHANGE REPLICATION SOURCE里SOURCE_SSL的事） - 不同 MySQL 版本生成的
.mylogin.cnf格式一致，但旧客户端（
主从复制中怎么用 login-path 替代明文密码？
主从复制本身不直接读 .mylogin.cnf，必须手动把 mysql_config_editor 存的凭据转成复制命令能用的形式。核心动作是：先用 login-path 连上主库查 SHOW MASTER STATUS，再用同一组凭据构造 CHANGE REPLICATION SOURCE 语句。
实操建议：
- 先创建 login-path：
mysql_config_editor set --login-path=master --host=10.0.1.10 --user=repl --password，输密码后回车 - 验证是否可用：
mysql --login-path=master -e "SHOW MASTER STATUS\G" - 执行 CHANGE 时，不能写
SOURCE_USER='repl', SOURCE_PASSWORD='xxx'—— 而要靠--defaults-extra-file或脚本注入，更稳妥的是用mysql --login-path=master -Nse "SELECT @@hostname, @@server_id"做前置校验，再拼接 SQL
为什么 CHANGE REPLICATION SOURCE 里填 login-path 名会失败？
CHANGE REPLICATION SOURCE TO SOURCE_USER='... 这类语法只接受字面字符串，不解析 login-path。MySQL 复制线程启动时不会加载 .mylogin.cnf，它压根不知道这个机制的存在。
典型错误现象：ERROR 1064 (42000): You have an error in your SQL syntax...，因为写了 SOURCE_USER='@login-path=master' 这种非标准写法。
- 参数差异：login-path 是客户端工具（mysql、mysqldump）用的，复制配置是服务端 SQL 层解析的，二者完全隔离
- 性能/兼容性影响：想“自动注入”就得套 shell 脚本或 Python 封装，增加部署复杂度；MySQL 8.0.22+ 支持
REPLICATION APPLIER权限模型，但依然不打通 login-path - 真正省事的做法：把
mysql_config_editor当作密码保险箱，用mysql --login-path=master -Nse "SELECT Variable_value FROM performance_schema.global_variables WHERE Variable_name='gtid_mode'"类命令辅助判断主库状态，而不是让它参与复制链路
比 mysql_config_editor 更安全的替代方案有哪些？
如果环境允许，优先用操作系统级凭据管理，而不是依赖 MySQL 自带工具。比如 Linux 上用 libsecret + gdbus，或 HashiCorp Vault 的 short-lived token。
但注意现实约束：
- MySQL 官方不支持 Vault 插件直连复制配置；你得写 wrapper 脚本，在
START REPLICA前临时 fetch token 并写入内存变量 - Docker/K8s 场景下，用
Secret挂载到容器内，再通过ENTRYPOINT注入环境变量，比.mylogin.cnf可控得多 - 最容易被忽略的一点：哪怕用了 Vault，
SHOW REPLICA STATUS\G输出里仍会显示Source_User: repl—— 用户名始终明文可见，密码字段才被隐藏。别指望靠这个躲过所有审计项
