MySQL 8.4 升级后旧账号连不上：mysql_native_password 迁移到 caching_sha2_password 的实战步骤

发布窗口刚过五分钟，订单服务的连接池开始报 Access denied，而同一套账号在旧库上还能正常登录。不少团队碰到这类问题第一反应是密码输错或者网络不通，真正的根因往往出在 MySQL 8.4 升级上：老账号依赖的 mysql_native_password 默认不再启用，服务端已经不再接受这个认证方式的登录请求。

这次认证不通过不是账号记录丢了，是升级后服务端直接禁用了旧的认证插件，哪怕你输入的密码完全正确，也无法完成建连。要彻底解决问题，得把存量账号逐个平滑迁移到 MySQL 8.4 新的默认认证体系下，临时开兼容开关只能当作过渡手段。

先认清 MySQL 8.4 改了什么

这不是驱动突然变严格。MySQL 8.4 把 caching_sha2_password 作为默认认证插件，已经被标记弃用的 mysql_native_password 在服务端默认禁用；继续依赖它的账号，升级后大概率会在建连阶段失败。MySQL 8.4 仍保留一个临时兼容开关，但 MySQL 9.0 已经彻底移除了旧插件，把开关当长期方案只是在推迟下一次升级的故障风险。

排查的时候先把“账号仍存在”和“账号可被当前服务端认证”分开看。账号记录还在，不等于绑定的认证插件可用；应用能偶尔复用之前留着的旧连接，也不等于重连一定能成功。

在升级窗口前盘点旧认证账号

先在预发环境或者从库跑一遍盘点。别着急直接修改 mysql.user，认证相关字段要通过账号管理语句变更。

SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'mysql_native_password'
ORDER BY user, host;

查询结果要和应用配置、定时任务、BI工具以及运维脚本逐个对应。最容易漏掉的是只在夜间跑一次的归档任务，白天做压测当然完全覆盖不到。建议把下面几类账号单独标记出来：

为什么首连校验比“能连一次”更重要

caching_sha2_password 会在服务端保存认证缓存。账号刚创建、刚改完密码、改过认证插件、执行过 FLUSH PRIVILEGES 或者数据库重启后，第一次连接不能只靠缓存走流程。这时候需要走安全传输，或者让客户端能拿到RSA公钥完成密码交换。

所以迁移演练要故意做一次冷启动：重启测试库或者清空认证缓存之后，再让每个应用重新建连。只验证保留了缓存的热连接，很容易把首连的问题藏到真正的发布窗口里。

按应用账号灰度迁移到 caching_sha2_password

先从低风险服务账号开始操作，改完立刻用对应服务在用的驱动和连接串建一个全新的连接。下面的示例会重置该账号的密码；生产操作前要从受管密钥系统取对应值，别把真实密码写进SQL文件或者聊天记录里。

ALTER USER 'order_api'@'10.%'
  IDENTIFIED WITH caching_sha2_password BY 'replace-with-managed-secret';

SELECT user, host, plugin
FROM mysql.user
WHERE user = 'order_api';

如果应用通过TCP访问数据库，优先把TLS连通性作为验收项。没法立刻启用TLS的环境，要确认客户端和服务端的RSA公钥交换配置；不要为了跳过这个检查把连接降级成明文传输密码的不安全模式。

迁移的常规顺序是：预发账号 → 单台线上实例 → 同一服务其余实例 → 其余服务账号。每一步都观察新建连接数、认证失败日志和接口错误率。这里的重点不是改SQL的速度，是确认连接池销毁旧连接之后，新连接还能正常恢复。

临时兼容开关应该放在什么位置

确实有遗留客户端短期内没法升级的情况，MySQL 8.4可以在服务端配置里临时设置 mysql_native_password=ON，让旧账号恢复可用。这是用来争取迁移时间的手段，不是最终修复：它只是保留已经弃用的认证路径，也解决不了 MySQL 9.0 已经彻底移除旧插件的问题。

把这个开关和到期日期一起写到变更单里，同时记录还没迁移的账号、对应的服务负责人和驱动升级计划。等最后一个旧账号完成迁移，再移除开关并做一次冷启动回归，才算真正收尾。

发布前后各做一次小而严的核对

• 发布前：导出旧认证账号列表，确认每个账号都能找到对应的所属服务。
• 发布中：每改完一个账号，就从对应应用的容器或者服务器上发起全新连接做验证。
• 发布后：持续观察认证失败日志、连接池建连失败数和接口错误率。
• 回退边界：仅在MySQL 8.4的短期窗口内使用旧插件开关，把未迁移账号明确标注为风险项。

一次平稳升级的标志不是“数据库启动成功”，是旧连接被替换之后，所有实际调用方都能正常完成认证。把账号盘点和冷启动首连步骤写到升级检查清单里，后面升级补丁版本的时候也能直接复用。

相关问题

能不能只修改 default_authentication_plugin？

别把它当成 MySQL 8.4 的完整迁移方案。新建账号的默认行为和存量账号用的认证插件是两回事，存量账号还是要逐个盘点和迁移。

改成 caching_sha2_password 后为什么只有第一次连接失败？

先排查TLS或者RSA公钥交换配置。认证缓存命中之后连接表现可能完全正常，但缓存清空、服务重启或者密码变更之后，会重新触发首连校验逻辑。

旧 JDBC 或其他驱动一定不能用吗？

不能只凭版本号直接下判断。用对应版本的驱动、实际的连接参数和冷启动后的数据库做一次真实建连测试，再决定是升级驱动还是调整安全连接配置。

临时启用旧插件后还需要迁移吗？

需要。临时开关只是给遗留系统留出改造窗口，后续大版本已经不再提供旧插件，迁移计划不能省。

收尾：把认证改造变成可重复的升级动作

这次改造真正值得沉淀的是两份清单：哪些账号还在依赖旧认证，哪些客户端能在冷启动之后正常安全建连。账号归属清晰、灰度步骤足够细碎、首连验证全部做完，MySQL 8.4的认证变化就不会在发布夜里变成无从下手的故障。