MySQL 密码特殊字符引发的登录异常

一、问题现象：诡异的登录差异

某运维人员通过脚本批量创建 MySQL 用户时，发现一个奇怪现象：应用程序使用自动生成的密码能正常访问数据库，但手动使用mysql客户端登录时却提示 "Access denied"。经过排查，异常用户的密码均包含特殊字符$，如密码abc$2UY。

问题复现

1. 脚本创建用户：
   简化的创建脚本如下，密码变量用双引号定义：

   # 脚本内容
   #!/bin/bash
   pw="abc$2UY"
   mysql --login-path=root -e "create user app@'%' identified by '$pw'"
   mysql --login-path=root -e "grant insert,update,delete,select on *.* to app@'%'"
   

    
2. 登录测试：
   • 手动输入密码abc$2UY：登录失败（ERROR 1045）。
   • 使用命令行带密码（单引号包裹）：mysql -h127.0.0.1 -uapp -p'abc$2UY'，登录失败。
   • 命令行不带引号或用双引号：mysql -h127.0.0.1 -uapp -pabc$2UY，登录成功。

二、根源剖析：Shell 解析机制与密码存储的冲突

1. Shell 中引号的解析差异

问题的核心在于Shell 对不同引号的处理逻辑：

• 双引号（" "）：会解析字符串中的变量（如$var）和命令（如$(cmd)），将其替换为实际值后再执行。
• 单引号（' '）：将字符串视为纯文本，不解析任何变量或特殊字符，原样保留。

在上述脚本中，密码pw="abc$2UY"用双引号定义，Shell 会将$2视为位置参数（类似脚本传入的第二个参数）。由于脚本未传入参数，$2被解析为空，实际传递给 MySQL 的密码为abcUY（而非预期的abc$2UY）。

2. 密码存储与登录的不匹配

• 存储的密码：脚本执行后，MySQL 中实际存储的密码是abcUY（因$2被解析为空）。
• 手动登录的密码：用户输入abc$2UY时，Shell 未解析$2（或用单引号保护），导致输入的密码与存储的abcUY不匹配，登录失败。
• 不带引号的登录：mysql -pabc$2UY中，Shell 解析$2为空，实际传递的密码是abcUY，与存储值一致，因此登录成功。

三、扩展场景：其他特殊字符的问题

1. 密码包含#与login-path的兼容问题

login-path是 MySQL 的免密登录配置工具，但在处理含#的密码时存在历史 bug：

• 问题表现：若密码为123#abc，直接配置login-path会失败，因#在配置中被视为注释符。
• 临时解决方案：在输入密码时用双引号包裹（如输入"123#abc"）。
• 版本修复：该 bug 在 MySQL 5.7.33 和 8.0.23 版本中被修复，之后版本无需额外处理。

2. 其他特殊字符的潜在风险

除$和#外，!、&、*等特殊字符也可能被 Shell 解析，导致密码异常：

• 例如，密码pass!word在 Shell 中，!可能被解析为历史命令调用，需用单引号保护（'pass!word'）。

四、解决方案与最佳实践

1. 特殊字符的正确处理方式

• 使用单引号定义密码：在脚本或命令中，用单引号包裹含特殊字符的密码，避免 Shell 解析：
   

  # 正确示例：单引号保护密码
  pw='abc$2UY'  # 变量定义时用单引号
  mysql --login-path=root -e "create user app@'%' identified by '$pw'"  # 引用变量时仍用双引号，但变量本身已被单引号保护
  

   
• 添加转义字符：对特殊字符前加\转义，强制 Shell 将其视为普通字符：
   

  pw="abc\$2UY"  # 用\转义$，避免被解析为变量
  

   

2. 规避策略

• 优先避免特殊字符：创建密码时尽量不使用$、#、!等易被解析的字符，减少复杂度。
• 版本适配：若使用login-path且密码含#，确保 MySQL 版本为 5.7.33 + 或 8.0.23+，无需额外处理；旧版本需用双引号包裹密码。
• 密码验证：创建用户后，通过select user,host,authentication_string from mysql.user where user='用户名';查看加密后的密码，与预期密码的加密结果对比（可手动创建相同密码的测试用户验证）。