为什么MySQL 8.0默认认证插件更改影响旧版DML连接？
来源：互联网 2026-07-22 08:40:08MySQL8.0默认认证插件caching_sha2_password致旧版DML工具连接失败。需ALTERUSER指定host、密码改回mysql_native_password，再FLUSHPRIVILEGES。注意host精确匹配，工具可能因SSL或时区配置不当导致查询异常。
MySQL 8.0 默认认证插件改成了 caching_sha2_password，这直接导致一批老牌 DML 工具——比如 Na vicat 12、DBea ver 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'@'%'是三个独立的账号，Na vicat 默认走127.0.0.1，你只改了localhost就等于白忙一场。- 云数据库（比如阿里云 RDS）通常没有修改配置文件的权限，这条路走不通，只能靠
ALTER USER来调。 - 如果返回结果里
plugin确实是caching_sha2_password，而你用的正好是 Na vicat 12、DBea ver 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 必须和你实际连接时用的完全一致：Na vicat 默认填
127.0.0.1，就别只改localhost，否则改完也没用。 - 改完立刻执行：
FLUSH PRIVILEGES;，部分 MySQL 8.0.22 及更早小版本不刷就不生效，这个坑不少人都踩过。 - 密码里如果含有
@、/、!等特殊字符，命令行登录时记得加单引号：mysql -uapp_user -p'pass!@#'，否则 shell 会解析错误。
GUI 工具连得上但查不出数据？可能是驱动参数没配齐
即使服务端已经切回 mysql_native_password，Na vicat 或 DBea ver 还可能卡在握手后的阶段——因为 MySQL 8.0 驱动默认校验时区和 SSL，旧连接配置如果没有明确声明，就会静默失败，表现为连上了但查询超时或报错。
- Na vicat：编辑连接 → 高级 → 勾选“使用 SSL”并设为“可选”，或者手动在连接字符串末尾加
&useSSL=false&serverTimezone=Asia/Shanghai。 - DBea ver：连接设置 → 编辑驱动属性 → 添加
useSSL=false、serverTimezone=Asia/Shanghai、allowPublicKeyRetrieval=true。 - 有些老版工具会缓存连接参数，改完服务端必须完全退出重开，否则它还在用旧握手流程重试，怎么改都没用。
真正容易被忽略的，往往不是插件切换本身，而是 host 的精确匹配、密码字段是否被意外清空、以及 GUI 工具对连接参数的缓存行为——这三个点比协议差异更常导致“改了还是连不上”的尴尬局面。