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，说明这条路走不通，得换方案。
客户端不支持 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 的连接池预热），否则你以为修好了，其实连的还是旧会话。
