最可靠方法是直接修改用户认证插件而非全局配置，尤其在云数据库或生产环境；先查目标用户实际使用的plugin：SELECT user, host, plugin FROM mysql.user WHERE user = 'your_username';注意替换真实用户名、host严格匹配（如'localhost'与'127.0.0.1'不同），若plugin为caching_sha2_password且客户端为JDBC 5.1.x或PyMySQL需适配。
直接改用户认证插件最可靠，别碰全局配置——尤其在云数据库或生产环境。
查清楚当前用户用的是哪个 plugin
连接不上不是凭感觉猜的，先登录 MySQL 命令行（mysql -u root -p），执行：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_username';
注意三点：
-
your_username要替换成你实际连接用的用户名，比如app_user或root -
host必须完全匹配：'localhost'、'127.0.0.1'、'%'是三个独立条目，Navicat 默认走127.0.0.1，但你可能只改了'localhost'，漏掉前者 - 如果
plugin列显示caching_sha2_password，且你用的是 JDBC 5.1.x、PyMySQL
用 ALTER USER 切换单个用户的认证方式
这是唯一在所有 MySQL 8.0+ 环境（包括阿里云 RDS、腾讯云 CDB）都立即生效的方法。语句必须带密码，否则会清空密码导致锁死：
ALTER USER 'your_username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
常见错误和要点：
- 不能只写
SET PASSWORD或ALTER USER ... IDENTIFIED BY ...—— 这不会改 plugin，只是重设哈希值，仍走caching_sha2_password握手流程 - 主机名要一字不差：
'your_username'@'127.0.0.1'和'your_username'@'localhost'得分别执行 - 改完必须立刻执行
FLUSH PRIVILEGES;，部分小版本（如 8.0.22 及更早）不刷权限就无效 - 密码需满足
validate_password策略（默认要求 ≥8 位、大小写字母+数字+特殊字符），旧弱密码可能被拒绝，别卡在这儿还怀疑插件没切成功
为什么 default_authentication_plugin 配置经常失效？
很多人改了 /etc/my.cnf 里的 default_authentication_plugin = mysql_native_password 却发现连不上，原因很实在：
- 这个配置**只影响新创建的用户**，对已存在的
root、app_user等完全无效 - 云数据库（RDS/CDB）通常禁止修改配置文件，这条路根本走不通
- 即使自建库改了并重启
mysqld，也得再对老用户单独跑一遍ALTER USER，否则毫无意义 - Docker 镜像若未挂载配置或启动参数被覆盖，
my.cnf修改可能压根没加载
客户端侧绕过方案的现实限制
某些驱动声称支持 allowPublicKeyRetrieval=true 或 useSSL=false 来“兼容” caching_sha2_password，但要注意：
- JDBC 5.1.x 完全不识别
allowPublicKeyRetrieval参数，加了等于没加，握手阶段直接报Authentication plugin 'caching_sha2_password' cannot be loaded - PHP 的老旧
mysqlnd（如 PHP 7.1 自带）即使用户插件已切为mysql_native_password，也可能因驱动 bug 报 SSL 错误或静默失败 -
~/.my.cnf里配default_authentication_plugin只对本地mysql命令行有效，不影响 Java/Python 应用连接
真正容易被忽略的点是：Navicat、DBeaver 这类工具会缓存连接握手参数，改完服务端后不关闭重开软件，或不删旧连接重建，它可能还在用旧的认证路径反复失败。
