MySQL 8.0+默认认证插件是caching_sha2_password,因其支持SHA-256哈希、RSA加密握手及服务端缓存优化以提升安全性;但旧客户端兼容性差,需确认报错信息后优先升级驱动,仅当不可行时才通过ALTER USER逐个切换或配置default_authentication_plugin(仅影响新建用户)。

直接结论:别急着切回旧插件,先确认是不是真需要切——多数情况是客户端驱动太老,升级比降级更稳妥;只有当升级不可行时,才用 ALTER USER 切换认证方式,且必须对每个 user@host 单独操作。
怎么确认真是 caching_sha2_password 在报错
错误信息里明确出现 Authentication plugin 'caching_sha2_password' cannot be loaded、Public Key Retrieval is not allowed 或 The server requested authentication method unknown to the client,基本就是它。但别猜,进 MySQL 执行:
-
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';—— 看plugin列是不是caching_sha2_password -
SHOW VARIABLES LIKE 'default_authentication_plugin';—— MySQL 8.4+ 这个变量已废弃,返回空也不代表没在用
注意:'user'@'localhost' 和 'user'@'%' 是两个独立用户,'user'@'127.0.0.1' 也算一个,必须分别查、分别改。
ALTER USER ... IDENTIFIED WITH mysql_native_password 为什么有时失败
常见失败原因不是语法错,而是环境限制:
- MySQL 8.4+ 默认禁用
mysql_native_password插件,执行会报ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded - 云数据库(如阿里云 RDS)不允许加载该插件,
ALTER USER直接拒绝 - 密码字段含特殊字符(如
@、\)导致 SQL 解析失败,建议先用纯字母数字密码测试 - 没加
BY 'password'——IDENTIFIED WITH mysql_native_password单独写会清空密码,登录直接被拒
如果报 Plugin 'mysql_native_password' is not loaded,说明这条路走不通,得换方案。
构建并排查Microsoft Word邮件合并及DOCX模板工作流,使用合并域、内容控件、文档属性、重复区块、数据等
客户端不支持 caching_sha2_password 时的替代方案
不能切插件?那就让客户端适配它:
- Java/JDBC:连接串加
?allowPublicKeyRetrieval=true&useSSL=false,并确保用 Connector/J 8.0+ 驱动 - Python/PyMySQL:升级到
pymysql >= 1.0.2,旧版不识别新插件标识符 - PHP:确认
mysqli和pdo_mysql扩展已启用,PHP 7.4+ 原生支持,7.3 及更早需升级扩展或打补丁 - Navicat/DBeaver:升级到最新版;若无法升级,改用命令行工具临时连,再执行修复操作
注意:加 allowPublicKeyRetrieval=true 是开发/测试环境可接受的权宜之计,生产环境应优先升级驱动或启用 TLS。
改 my.cnf 的 default_authentication_plugin 有用吗
只对新建用户生效,对已有用户完全无效。而且:
- MySQL 8.4+ 已弃用该配置项,应改用
authentication_policy=mysql_native_password - 即使配置生效,也需重启 MySQL 服务,云数据库通常不开放此权限
- 宝塔、Docker 等环境改完配置不重启,等于没改;重启后旧连接池可能缓存旧状态,仍报 IO 线程失败
真正容易被忽略的是:所有修复操作后,必须检查客户端是否还缓存了旧连接参数(比如 Navicat 的连接配置、Spring Boot 的连接池预热),否则你以为修好了,其实连的还是旧会话。










