根本原因是mysql 8.0默认使用caching_sha2_password认证插件，而旧客户端（如jdbc 5.x、navicat旧版）不支持该协议，导致认证握手失败；解决需alter user明确指定'user'@'host'并执行flush privileges，或升级驱动/工具。
根本原因不是密码没改对，而是 MySQL 8.0 默认用 caching_sha2_password 插件加密，而旧程序（含 JDBC 5.x、Navicat 旧版、老版 Workbench）压根不认这个协议——连接时直接卡在认证握手阶段，报错如 Authentication plugin 'caching_sha2_password' cannot be loaded 或 Client does not support authentication protocol requested by server。
ALTER USER 必须带 host，否则无效
这是最常踩的坑：只写 ALTER USER 'root' IDENTIFIED WITH mysql_native_password BY 'pwd'，MySQL 不知道你要改哪个 root。用户是 user@host 的组合，host 错了就等于改了别人。
- 本地连接必须明确指定
'root'@'localhost'（注意单引号和 @ 符号） - 远程连接要用
'root'@'%'或具体 IP，比如'appuser'@'192.168.1.100' - 执行完必须跟
FLUSH PRIVILEGES;，重启 MySQL 不必要，但漏掉这句修改就不生效
jdbc 连接串缺参数，连得上但查不出数据
换了驱动类名、改了认证插件，还可能“能连不能查”——因为 MySQL 8.0 驱动默认强制校验服务端时区和 SSL，旧连接串没声明就会静默失败。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 驱动类名必须是
com.mysql.cj.jdbc.Driver，com.mysql.jdbc.Driver在 8.x 中已彻底删除 - 连接串必须带
serverTimezone=Asia/Shanghai（不能空、不能靠系统默认） -
useSSL=false在开发环境必须显式加，否则握手卡死 -
allowPublicKeyRetrieval=true是 8.0.4+ 必需参数，尤其当密码加密方式切换后 - 完整示例：
jdbc:mysql://localhost:3306/test?serverTimezone=Asia/Shanghai&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true
Workbench 或 Navicat 报 ER_NOT_SUPPORTED_AUTH_MODE
这类 GUI 工具通常不会自动适配新认证协议，错误提示直白但误导性强——它不是密码错，也不是网络不通，就是协议不匹配。
- Workbench 7.x 及更早版本不支持
caching_sha2_password，改插件是唯一解法 - Navicat 12.0.24 之前版本同样不支持，升级到 15+ 才原生兼容
- 不要去改
my.cnf里的default_authentication_plugin，实测无效；也不要指望客户端“降级设置”，服务端不配合没用 - 如果必须用旧工具，就只对开发账号切回
mysql_native_password，生产账号仍应保留caching_sha2_password
真正容易被忽略的是：改完认证插件后，旧连接串里如果还残留 useSSL=true 或没设 allowPublicKeyRetrieval=true，照样会失败——错误日志可能只显示“Connection refused”或空结果，根本看不出是参数问题。
