根本原因是MySQL 8.0默认使用caching_sha2_password认证插件，而旧客户端不支持；执行ALTER USER后仍连不上，常见因未FLUSH PRIVILEGES、host不匹配、客户端缓存或驱动/参数配置不当。
MySQL 5.7 升级到 8.0 后连接失败，根本原因不是密码错了，而是服务器默认改用 caching_sha2_password 插件认证，而你的客户端（DBeaver、Navicat、旧版 JDBC/PyMySQL）不支持它——这不是配置错误，是协议升级带来的兼容性断层。
为什么 ALTER USER 切换插件后还是连不上
执行了 ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password BY 'pwd'，但客户端仍报错，常见原因有三个：
- 没刷新权限：
FLUSH PRIVILEGES必须执行，否则变更不生效 - 用户 host 匹配不对：比如你连的是
user@'192.168.1.%'，但只改了'user'@'localhost'，得确认实际连接来源的 host - 客户端缓存了旧握手信息：某些 GUI 工具（如老版 Navicat）会复用连接池或预加载插件，重启工具本身比重启 MySQL 更有效
my.cnf 里设 default_authentication_plugin 为什么没用
在 [mysqld] 段加了 default_authentication_plugin = mysql_native_password，但重启后新用户还是用 caching_sha2_password，问题出在：
当用户希望自动格式化、排版或美化 Word（`.docx`）文档时，应使用此技能。触发语包括： - “帮我排版这个Word” - “自动格式化文档” - “统一字体行距” - “论文/报告排版” - “Word排版” - “整理文档格式” - “format this Word file” - “auto typeset” - “standardize document style” 该技能提供一个 Python 脚本（`word_formatter.py`），可
- 配置项只影响「新建用户」，已有用户（包括 root）的
plugin字段不变，必须单独ALTER USER - 云数据库（阿里云 RDS、腾讯云 CDB）通常屏蔽该配置项，修改会被忽略，
SHOW VARIABLES LIKE 'default_authentication_plugin'会显示仍是caching_sha2_password - systemd 下必须用
sudo systemctl restart mysqld，reload不触发插件重载，配置不会生效
Java 应用连 MySQL 8.0 报 handshake 错误怎么办
即使服务端已切回 mysql_native_password，JDBC 连接仍卡在握手阶段，大概率是驱动版本或连接参数不匹配：
- 用 MySQL Connector/J 8.0+ 驱动，但连接串缺关键参数：
?serverTimezone=UTC&allowPublicKeyRetrieval=true&useSSL=false—— 其中allowPublicKeyRetrieval=true是绕过 RSA 密钥交换的必需开关 - 若用 5.1.x 驱动，它根本不认识
caching_sha2_password，也不支持allowPublicKeyRetrieval参数，必须升级驱动 - Spring Boot 2.4+ 默认启用 SSL，
useSSL=false不加会导致握手超时，而非明确报错
DBeaver / Navicat 连接时如何绕过插件限制
不想动服务器配置？客户端侧有更轻量的解法：
- DBeaver：新建连接 → SSH/SSL 标签页 → 勾选「Use SSL」→ 在「Driver properties」里手动添加
allowPublicKeyRetrieval=true和useSSL=false - Navicat：连接设置 → 「高级」选项卡 → 勾选「使用旧版身份验证」（Navicat 12.1+ 提供该开关）
- 命令行临时指定：
mysql -u app_user -p --default-auth=mysql_native_password，适用于调试，不建议写进脚本长期依赖
真正容易被忽略的是：caching_sha2_password 的安全增强（SHA-256 + 缓存 + 可选 RSA 加密）不是“多此一举”，而是 MySQL 8.0 的默认水位线。你在开发环境降级插件很轻松，但在生产环境批量执行 ALTER USER ... IDENTIFIED WITH mysql_native_password，等于主动关闭一项基础安全能力——尤其当应用本身不强制走 SSL 时，密码哈希可能以较弱方式暴露在网络路径中。
