-p 后面直接跟密码，连库最快，也最容易进 ps 和 shell 历史。终端标题栏有时还会挂着整段命令。MySQL 8.4 手册的 End-User Guidelines for Password Security 把常见写法按风险排过一遍。专门存登录信息的工具则是 mysql_config_editor。这篇只谈客户端怎么把密码从命令行挪走，不谈 Agent 外层 shell 怎么包命令。
.mylogin.cnf 实际存的是什么
mysql_config_editor set --password 一类命令，会把 host、user、password、port、socket 写进登录路径文件 .mylogin.cnf（非 Windows 一般在用户主目录，Windows 在 %APPDATA%\MySQL）。文件内容是**混淆（obfuscation）**后的格式，客户端读取时在内存里还原，不必再把密码写进命令行或环境变量。print 时密码也会显示成 *****。
用的时候指定登录路径即可，例如：
mysql_config_editor set --login-path=client --host=127.0.0.1 --user=app --password
mysql --login-path=client
默认登录路径名是 client。客户端仍会读其他 option file 里的 [client] / [mysql] 等组。加了 --login-path=名字 时，再额外读这个命名路径。.mylogin.cnf 的优先级高于普通 option file，但低于命令行显式参数。即便加了 --no-defaults，只要没加 --no-login-paths，客户端仍会读登录路径文件——官方的意图就是：即使跳过其他默认配置，也能用更安全的方式带上密码。
文件权限有硬要求：必须仅当前用户可读写，对其他人不可访问。否则 mysql_config_editor 和客户端都会忽略它。改完权限却发现登录路径「不生效」，先查是不是被当成对其他人可读了。
混淆不是「管理员也打不开」
配置工具页写得很直：混淆避免明文出现在文件里，能减少无意间把密码亮给旁边人看的情况。不足以挡住有系统管理权限、能读你文件的攻击者，也不该当成不可破的加密。密码安全用户指南里把它列进更稳妥的做法之一（该页用词是 encrypted login path file），同页的 mysql_config_editor 专章则强调 obfuscation 与「不可当不可破加密」。两页合在一起读：日常防的是误展示和命令行泄露，不是防本机管理员。
和其他写法怎么比
同一份用户指南里的对照大致是：
mysql -ppassword/--password=…：方便但不安全。部分系统上ps能看到。客户端初始化时常把 argv 里的密码覆写成零，仍有短暂可见窗口，有的系统覆写无效。终端标题栏也可能一直显示命令。- 交互式
-p（后面不跟值）：客户端提示输入，输入时不回显，比写在命令行安全。只适合人在键盘前的场景，脚本非交互跑不了。 ~/.my.cnf等 option file 明文写password=：权限应设为400或600。相对命令行好一些，但文件本身是明文，备份、同步、误cat时仍可能漏。.mylogin.cnf：不明文。权限不对就直接不用。仍防不住本机高权限用户花力气还原。
环境变量、把密码塞进 argv 拼给自动化工具，风险模型和「写在命令行」接近。若是 Agent 代跑客户端、外层 shell 把整段命令挂在进程列表里，那是另一条线——同批有一篇专写进程列表和 argv，和这篇「客户端怎么存证」分开看即可，这里不展开命令包装细节，也不发明未发布帖的站内链接。
本机多环境可以用多个 login path（本地、只读从库、跳板后的远程），用名字切换，少在脚本里硬编码。set 时不必一次写满所有字段，缺的 host 或 port 可以在连接时用命令行补，命令行仍覆盖登录路径里的同名项。团队共享机器上，每人用自己的 .mylogin.cnf，别把同一份混淆文件拷来拷去当「加密分发」。
你们现在脚本连库，是交互 -p、600 的 .my.cnf，还是已经迁到 mysql_config_editor？迁的时候踩过权限被忽略的坑吗？