根本原因是shell或配置文件提前解析了特殊字符，而非MySQL不支持；应绕过shell解析，优先使用mysql_config_editor安全存密，禁用命令行传参和配置文件明文密码。
MySQL里密码含@、/、:、$等字符导致授权失败，根本不是MySQL不认这些字符，而是shell或配置文件提前把它们“吃掉”了——解决的关键是绕过shell解析，而不是给密码加转义。
mysql命令行传参时密码被截断
直接执行mysql -u root -p'pa@ss/wd:123'会失败，因为shell把@当协议分隔符、:当端口分隔符、/当路径分隔符，实际传给MySQL进程的密码只剩pa或pa@ss/wd之类残缺片段。
- 永远不要在命令行用
-p'xxx'或-p"xxx"传含特殊字符的密码 - 如果必须临时用，改用交互式输入：
mysql -u root -p回车后手动粘贴密码（终端不显示，但支持完整粘贴） - 脚本中绝对禁止硬编码密码——哪怕加了引号也拦不住shell预解析
SQL语句里CREATE USER或ALTER USER报错
在MySQL客户端内执行CREATE USER 'u'@'%' IDENTIFIED BY 'p@ss#word!'本身完全合法，MySQL服务端能原样接收和哈希。出错往往是因为你误加了反斜杠转义，比如写成'p\@ss\#word\!'——这会让MySQL真去存带反斜杠的密码，后续登录必须输p@ss#word!反而登不上。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- SQL中密码必须用单引号包裹，且内部不转义任何字符
- 如果密码本身含单引号（如
pa'ss），改用双引号并转义内部单引号："pa\'ss/wd" - 认证插件要匹配：MySQL 8.0+默认
caching_sha2_password，旧客户端连不上时，显式指定IDENTIFIED WITH mysql_native_password BY 'p@ss#word!'
用mysql_config_editor安全存密
这是唯一推荐的长期方案：密码加密存进~/.mylogin.cnf，所有MySQL客户端工具（mysql、mysqldump等）自动读取，全程不经过shell，彻底避开解析问题。
- 执行
mysql_config_editor set --login-path=prod --user=myuser --host=localhost --password，回车后粘贴含任意特殊字符的密码 - 立刻验证：
mysql --login-path=prod -e "SELECT USER();" - 检查文件权限：
ls -l ~/.mylogin.cnf必须是-rw------- (600)，否则MySQL拒绝读取
配置文件my.cnf里写password的风险
在[client]段写password = p@ss/wd:123看似简单，但某些客户端（尤其老版本或非官方驱动）会把:和/当成DSN格式的一部分，导致连接失败；更严重的是ini解析器也会按等号、冒号切段，结果比shell还脆。
- 配置文件里严禁明文写
password，这是硬性红线 - 若环境受限必须写，只能用于极简场景（如本地开发），且需确认所有用到该配置的客户端都兼容这种写法
- 真正安全的做法是删掉
password行，改用mysql_config_editor替代
最常被忽略的一点：错误往往发生在多个环节叠加时——比如你用脚本生成用户，脚本里又用mysql -e "CREATE USER ... IDENTIFIED BY '$pw'"，而$pw变量含$符号，shell先展开变量再传参，密码早就不对了。这种链路里的每一层都要单独验，不能只盯MySQL日志。
