MySQL 8.0升级后连接失败主因是客户端不支持caching_sha2_password插件,必须用ALTER USER显式切换用户认证方式为mysql_native_password并执行FLUSH PRIVILEGES,仅修改my.cnf中default_authentication_plugin对已有用户无效。

ALTER USER 必须显式执行,不能只改配置文件
升级后连不上,大概率不是密码错了,而是客户端根本没认出 caching_sha2_password 插件。你改了 my.cnf 里的 default_authentication_plugin = mysql_native_password,重启服务也没用——这个参数只在实例首次初始化(mysqld --initialize)时生效,对已有用户完全无效。
真正起效的操作是:用 root 或有 CREATE USER 权限的账号,对每个要兼容的老客户端用户单独执行:
ALTER USER 'app_user'@'10.20.1.%' IDENTIFIED WITH mysql_native_password BY 'real_password';
-
host必须完全匹配,比如原用户是'app_user'@'10.20.1.%',就不能简写成'app_user'@'%' - 如果密码为空或太弱(如
'123'),MySQL 8.0 可能直接拒绝执行,得先用SET PASSWORD设个强密码再改插件 - 执行后必须立刻跟一句
FLUSH PRIVILEGES,否则权限变更不生效,连接池(如 HikariCP、Druid)可能复用旧握手逻辑导致偶发失败
查 plugin 字段确认是否生效
别信“改完就通”,得亲眼看到插件已切换。登录 MySQL 后执行:
SELECT user, host, plugin FROM mysql.user WHERE user = 'app_user';
结果中 plugin 字段必须是 mysql_native_password,而不是 caching_sha2_password 或空值。注意:mysql.user 在 8.0 是视图,不能 UPDATE,只能靠 ALTER USER 修改。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录,或需要将该能力封装成可公开复用的 Codex skill。
- 批量检查所有非兼容用户:用
SELECT user, host, plugin FROM mysql.user WHERE plugin != 'mysql_native_password'; - 不要依赖
authentication_string字段内容判断——它存的是哈希值,看不出插件类型 - 如果查不到目标用户,说明
host不匹配,换用SELECT user, host FROM mysql.user;全局看一遍
客户端驱动版本比连接参数更重要
即使服务端已切回 mysql_native_password,老驱动仍可能在连接池复用、SSL 握手、时区协商等环节失败。这不是配置问题,是协议支持缺失。
- Java:必须用
mysql-connector-java ≥ 8.0.12,5.1.x 驱动根本不识别 8.0 的握手流程 - PHP:
mysqlnd ≥ 8.0.0(对应 PHP ≥ 7.4),PHP 7.3 及更早的mysqli扩展无法协商新协议 - Python:弃用已停止维护的
MySQLdb,改用pymysql或mysql-connector-python ≥ 8.0.12 - 连接串里加
?allowPublicKeyRetrieval=true&useSSL=false&serverTimezone=UTC是临时补救,不能替代驱动升级
主从复制场景下主库也得同步处理
如果迁移涉及主从结构,光改从库没用。5.7 主库 binlog 里不含 caching_sha2_password 所需元数据,而 8.0 从库默认要求该插件,会导致 IO 线程静默断开。
- 在 5.7 主库的
my.cnf中强制设default_authentication_plugin = mysql_native_password并重启 - 所有新建复制账号(如
'repl'@'%')必须显式创建:CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 禁止在 5.7 主库执行任何
ALTER USER ... IDENTIFIED WITH caching_sha2_password,否则后续 binlog 事件会卡住 8.0 从库 SQL 线程 - 检查
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set是否为空——为空说明 IO 线程根本没连上,优先排查认证失败
真正麻烦的不是单条命令写错,而是服务端改了、客户端没升、主库漏配、连接池缓存未清这四件事同时发生——它们叠加起来,会让错误表现得像“时好时坏”,最易被当成网络抖动忽略。










