MySQL 8.4 升级后连接失败怎么办：mysql_native_password 停用与客户端切换

MySQL 8.4 升级完成后，应用连接池突然出现认证失败，最容易误判成“密码变了”。真正需要先确认的是账号使用哪个认证插件，以及应用实际加载的客户端库是否认识它。本文只处理 mysql_native_password 停用带来的兼容问题，目标是完成一次可验证、可回退的客户端切换。

先查账号的认证插件和客户端版本，再决定是升级连接器，还是用 ALTER USER 将账号切到 caching_sha2_password；不要直接批量改所有账号。

升级范围：问题集中在认证插件和客户端边界

MySQL 官方 8.4 升级说明把认证插件列为需要检查的兼容面。mysql_native_password 已被标记为弃用，旧账号是否还能继续使用，不能只看服务端能否启动；还要看客户端在握手阶段能否加载服务端要求的插件。官方文档也提醒，来自不同 MySQL 系列的客户端与服务端组合更容易出现认证不兼容。

因此这次迁移拆成两条线：第一条确认账号当前的 plugin 值，第二条确认应用使用的 Connector、驱动或客户端库版本。只有两条线都通过，才算完成。

先做变更表：哪些现象对应哪一层风险

下面的检查使用只读查询；生产环境先在备库或测试实例演练，并为目标账号准备可回退的密码管理记录。

旧代码风险：账号插件和客户端能力可能错位

先以有权限的管理账号查看目标用户。查询结果中的 plugin 是服务端为该账号选择的认证方式，不能用配置文件里的默认值代替。

SELECT User, Host, plugin
FROM mysql.user
WHERE User = 'app_reader';

如果结果是 mysql_native_password，先记录账号、Host 和当前连接方式，不要马上改表。再用应用实际使用的客户端做一次独立连接测试；“mysql 客户端可以连接”只能证明这个命令行客户端可用，不能证明 Java、PHP、Python 或 Go 连接器都可用。

新写法：把目标账号切到 caching_sha2_password

确认客户端和连接器支持 caching_sha2_password 后，再对单个账号执行切换。ALTER USER 会重新设置该账号的认证插件和密码，密码值应在终端交互或受控密钥流程中输入，文章示例不放真实凭据。

ALTER USER 'app_reader'@'10.%'
  IDENTIFIED WITH caching_sha2_password BY '请替换为受控密码';

SELECT User, Host, plugin
FROM mysql.user
WHERE User = 'app_reader' AND Host = '10.%';

第二条查询应返回 caching_sha2_password。如果目标账号存在多个 Host 行，只改了其中一行，应用仍可能命中另一行；这也是切换后“有的机器能连、有的机器不能连”的常见来源。

回归检查：命令行成功还不够

检查应用连接池是否真正重建

让应用完成一次受控重启或连接池重建，再观察启动日志和第一条健康检查。重点看是否仍出现认证插件不识别、握手失败或连接被拒绝，而不是只看进程是否处于运行状态。

检查真实业务路径

用应用自己的账号完成一条只读查询，至少覆盖连接建立、连接归还、再次取连接三个动作。连接建立成功但连接池复用失败，说明旧连接或驱动配置仍未收口。

检查复制与管理账号

如果目标账号用于复制、备份或运维脚本，分别验证这些调用方。不要把业务账号切换成功当成所有账号都完成迁移。

迁移清单：按小范围、可回退的顺序落地

1. 列出所有应用账号、Host、用途和客户端版本。
2. 先在测试实例切换一个非核心账号，执行真实客户端连接和健康检查。
3. 升级不兼容的 Connector 或驱动，再按应用分批切换账号。
4. 观察认证失败日志和连接池重建结果，确认没有遗漏的 Host 行。
5. 保留原账号认证信息的受控回退方案；发现回归失败时只回退本批次。

回退不是把所有账号重新改回旧插件，而是先停止扩大变更范围，定位是账号、Host 还是客户端问题，再针对单个账号处理。MySQL 官方升级建议也强调先在测试环境确认应用行为，再进入生产升级。

常见问题

MySQL 8.4 升级后密码一定要重置吗？

不一定。先查账号的 plugin 和客户端兼容性；只有在切换认证插件时才需要按受控流程重新设置该账号密码。

为什么 mysql 客户端能连，应用还是失败？

两者可能使用不同的客户端库。应使用应用真实 Connector 建立连接，并检查连接池重建后的日志。

能不能直接批量执行 ALTER USER？

不建议。先按账号用途和 Host 分批，确认客户端支持 caching_sha2_password 后再扩大范围。

切换成功后还要看什么？

至少核对账号查询结果、应用健康检查、真实只读查询和复制/备份脚本；四项都通过才结束迁移窗口。

最后确认

这次迁移的关键不是记住一个替换命令，而是把认证链路拆开验收：服务端账号采用的插件、客户端库的支持能力、连接池重建后的真实业务请求。沿着这三层检查，MySQL 8.4 升级后的连接故障通常可以在小范围内定位和回退。