MySQL 9.x升级后连接异常大概率因默认认证插件切换为caching_sha2_password，旧客户端不兼容；需查mysql.user表确认plugin值，执行ALTER USER降级插件并FLUSH PRIVILEGES，或升级驱动+配置SSL参数。
MySQL 9.x 升级后应用连接异常，大概率不是“连不上”，而是连接被立即拒绝或认证失败——核心原因是默认认证插件从 mysql_native_password 切换为 caching_sha2_password，且旧版 JDBC 驱动、PHP MySQLi 扩展或某些 ORM 默认不兼容。
确认是否因认证插件变更导致失败
升级后首次连接失败，先登录 MySQL 服务端查用户实际使用的认证方式：
- 执行
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_app_user'; - 若
plugin值为caching_sha2_password，而你的客户端（如 Java 应用用的是 MySQL Connector/J 5.1 或更老版本）不支持该插件，就会报错Public Key Retrieval is not allowed或直接Access denied - 注意：即使密码正确，只要插件不匹配，认证就通不过
快速修复：临时降级用户认证插件
适用于测试环境或需快速恢复的场景，不推荐长期使用：
- 执行
ALTER USER 'your_app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 务必执行
FLUSH PRIVILEGES; - 重启应用（无需重启 MySQL）
- 验证连接是否恢复；若仍失败，说明问题不在插件层，需继续排查其他环节
根本解决：升级客户端驱动并启用安全连接参数
MySQL 9.x 强制要求 TLS 加密传输（除非显式禁用），且 caching_sha2_password 默认依赖 SSL 或公钥交换。仅升级驱动还不够，必须补全连接参数：
- Java（JDBC）：升级到 MySQL Connector/J 8.0.28+，连接 URL 加上
?allowPublicKeyRetrieval=true&useSSL=false（开发环境可暂用，生产必须配 TLS） - Python（PyMySQL）：升级到 PyMySQL 1.0+，并在
connect()中显式传参ssl_disabled=True或配置 CA - PHP（PDO）：使用
mysqli扩展 ≥ 8.0，连接时设置MYSQLI_OPT_SSL_MODE => MYSQLI_SSL_MODE_DISABLED（开发）或配置ssl_ca/ssl_cert - 关键点：
useSSL=false和allowPublicKeyRetrieval=true是临时绕过手段，生产环境必须部署有效证书并启用 TLS
检查 bind_address 和 max_connections 是否被重置
MySQL 9.x 安装包可能覆盖原有配置文件，导致远程访问失效或连接池瞬间打满：
- 检查
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf中的bind_address—— 若仍是127.0.0.1，远程应用会报Connection refused - 运行
SHOW VARIABLES LIKE 'max_connections';—— MySQL 9.x 默认值可能从 151 降到 100，高并发应用容易触发Too many connections - 修改配置后必须执行
systemctl restart mysqld，SET GLOBAL方式不持久
真正麻烦的不是插件切换本身，而是它暴露了应用长期没更新的底层依赖——比如还在用 JDBC 5.1 的老系统，往往同时存在连接池未关闭、SQL 注入风险、无 TLS 等一揽子问题。修复时别只打补丁，顺手把驱动版本、连接池配置和 TLS 证书都核一遍。
