MySQL 8.0 版本将默认认证插件更新为 caching_sha2_password，这一变更直接导致众多经典 DML 工具——例如 Navicat 12、DBeaver 4.x、旧版 MySQL Workbench——在连接阶段便遭遇失败。本质上，问题并非数据库本身出现故障，也不是网络连接不通畅，而是 TCP 握手之后的首轮认证协议双方无法匹配，工具根本没有机会进入“发送 SQL 语句”的环节，从而造成连接卡壳。
精准确认当前用户所使用的 plugin 类型
不要凭猜测操作，直接进入 MySQL 命令行执行以下查询：SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';
重点观察 plugin 列是否为 caching_sha2_password。这里有三个容易踩坑的细节需要留意：
'root'@'localhost'、'root'@'127.0.0.1'、'root'@'%'是三个彼此独立的账号，Navicat 默认走127.0.0.1连接，如果你只修改了localhost的配置，相当于做了无用功。- 云数据库实例（例如阿里云 RDS）通常不允许修改服务端配置文件，这条路行不通，只能通过
ALTER USER语句进行调整。 - 如果查询结果中
plugin字段确实为caching_sha2_password，而你使用的恰好是 Navicat 12、DBeaver 4.x 或 JDBC 5.x 等旧版工具，那么基本可以确定这就是导致连接失败的根源。
ALTER USER 必须同时包含密码、host 与 plugin 三要素
如果只写 ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password; 而不指定密码，系统会直接清空密码字段，等于把自己锁在门外；如果只写 SET PASSWORD 而不修改插件，认证时仍然会走 caching_sha2_password 握手流程，治标不治本，问题依旧存在。
- 正确写法示例：
ALTER USER 'app_user'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'your_pass'; - host 参数必须与你实际连接时使用的地址完全一致：Navicat 默认填写
127.0.0.1，就不要只修改localhost，否则改完仍然无法生效。 - 修改完成后立即执行：
FLUSH PRIVILEGES;，部分 MySQL 8.0.22 及更早的小版本如果不刷新权限就不会生效，这个坑不少用户都遇到过。 - 如果密码中包含
@、/、!等特殊字符，在命令行登录时记得加上单引号：mysql -uapp_user -p'pass!@#'，否则 shell 会解析错误导致登录失败。
GUI 工具能连接但查不出数据？可能是驱动参数未配置完整
即使服务端已经成功切换回 mysql_native_password，Navicat 或 DBeaver 仍可能卡在握手之后的阶段——因为 MySQL 8.0 驱动默认会校验时区和 SSL 配置，旧连接配置如果没有明确声明这些参数，就会静默失败，表现为连接成功但查询超时或直接报错。
- Navicat：编辑连接 → 高级 → 勾选“使用 SSL”并设为“可选”，或者手动在连接字符串末尾追加
&useSSL=false&serverTimezone=Asia/Shanghai。 - DBeaver：连接设置 → 编辑驱动属性 → 添加
useSSL=false、serverTimezone=Asia/Shanghai、allowPublicKeyRetrieval=true等参数。 - 部分旧版工具会缓存连接参数，修改服务端配置后必须完全退出工具并重新打开，否则它仍然沿用旧的握手流程重试，无论怎么改都无法生效。
在实际排查中，真正容易被忽略的往往不是插件切换本身，而是 host 的精确匹配、密码字段是否被意外清空、以及 GUI 工具对连接参数的缓存行为——这三个细节比协议差异更常导致“明明改了却还是连不上”的尴尬局面。