先分享一个真实场景：你费了半天劲把 MySQL 8.0 部署完，打开 Navicat 11 输完密码，结果对方甩回来一行英文：Client does not support authentication protocol requested by server; consider upgrading MySQL client。第一反应查密码、改权限、重启服务，折腾一圈，最后才发现不是密码问题，而是认证插件协议对不上。类似的情况还有 Navicat 12 连接时直接冒出一个1251错误码，网上搜一圈全是让改mysql_native_password的，改完发现还是模棱两可。
这篇文章就是专门解决这个问题的。我的建议很明确：从 Navicat 11/12 平滑升级到 Navicat 15，同时搞清楚 MySQL 8.0 默认的caching_sha2_password认证机制，升级之后该配置的配置、该验证的验证，基本一次搞定。如果你暂时不方便升级客户端，我后面也给了改用户认证方式的备选方案，并会说明为什么只适合过渡、不适合长期使用。内容同时覆盖数据库管理员、后端开发和刚接触 MySQL 的新手，只要跟着操作路径走，不需要你是专家。
1. 先从报错说起：1251 到底在抱怨什么
1.1 认证插件是什么，登录时到底发生了什么
很多人一听到“认证插件”四个字就头大，其实可以把它理解成“MySQL 验密码时用的算法协议”。你输入用户名和密码，MySQL 要按照双方都认可的方式完成校验。如果服务器和客户端使用不同算法，那对话根本进行不下去。
流程大概是这样的：你发起连接，MySQL 服务器告诉你“我这边支持哪些认证插件”，客户端要选择一个双方都能接受的插件去完成握手。如果服务器的默认插件是caching_sha2_password，而你的客户端驱动里根本没有实现这个插件，服务器就无法继续认证，直接返回错误。在旧版 Navicat 里，你看到的就是1251或者Client does not support authentication protocol。
这不是权限问题，也不是密码错误，而是“客户端太老，认不出服务器的新玩法”。所以网上一堆让你重置密码的教程，方向就是错的。
1.2 MySQL 8.0 为什么要换成 caching_sha2_password
老版本 MySQL 一直用mysql_native_password，这个插件基于 SHA1 做密码校验，设计年代早，后来已经谈不上安全。MySQL 官方从 8.0 开始把默认认证插件换成caching_sha2_password，本质上是用 SHA256 算法替代旧方案，并引入“服务端缓存”机制，让连续认证的用户可以有更快的验证路径。
caching_sha2_password这个名字拆开看也很好理解：caching表示加缓存，sha2是 SHA256 算法，password就是用它来验证密码。相比老方案，它在抗碰撞、防暴力破解方面都要强不少。MySQL 官方在 8.0 版本里将其设为默认，可以理解为一次安全层面的强制升级。
旧版 Navicat 11 发布于 MySQL 5.x 大行其道的年代，那时候客户端协议里只实现了mysql_native_password。当它遇到默认认证插件是caching_sha2_password的 MySQL 8.0，自然就卡住了。
1.3 旧版 Navicat 卡在哪一环，升级版本为什么能解决
问题出在客户端侧的认证协议库，不是你的服务器配置错了。Navicat 本身是个 GUI 工具，但底层要跟 MySQL 通信时还是走 MySQL 客户端协议。协议里如果不包含对新认证插件的支持，无论如何设置服务器端，都不可能从“根”上解决问题。
Navicat 15 及之后的版本，内部客户端库已经补足了caching_sha2_password的支持，所以升级客户端后被弹错误的问题自然会消失。整个过程不需要动数据库用户，不需要改认证方式，数据库侧完全无感。这也是我为什么一直推荐“升级 Navicat 优先于改服务器配置”：数据库侧零改动，业务风险最小。
2. 升级 Navicat 到 15：最省事的一条路线
2.1 升级前先备份连接配置，否则你会在手动重建连接上浪费一小时
Navicat 的连接配置是存在本地配置文件里的，升级新版本时有可能覆盖配置或者不在原位置读取。我不喜欢那种装完新版结果所有连接都要手动重填的经历，尤其是几十个连接加上 SSH 隧道、SSL 证书时，手动重建的体验极差。
Navicat 自带“导出连接”功能，可以把当前所有连接配置导出成一个文件，里面能包含主机地址、端口、用户名、连接名等。导出的时候会让你选择“是否导出密码”，如果勾选了，新版本导入后连密码都不用重新输。
具体路径是：连接列表页面顶部菜单栏找“文件” -> “导出连接”。导出的文件后缀通常是.ncx（老格式）或.npx（新格式）。建议导出文件名带上日期，我是习惯存到一个固定目录，比如~/navicat-backup/connections-2025xx.ncx。
2.2 安装新版并导入连接，需要留意三个隐藏选项
从 Navicat 11/12 升级到 15，安装过程并不复杂，直接下载对应操作系统版本安装即可。需要注意的三个细节是：
第一，不要选择覆盖安装在旧版本目录上，最好装到一个新的安装目录，避免 DLL 组件混杂导致奇怪的兼容性问题。第二，安装完成后先别急着删除旧版本，等新版本连接验证通过后再清理。第三，导入连接时如果发现密码为空或提示密码错误，多半是因为旧版导出的连接文件默认没包含密码，需要手动重新输一次密码。
导入路径同样是“文件” -> “导入连接”，选择之前备份的.ncx或.npx文件。导入后 Navicat 会列出连接，右键 -> “编辑连接”检查一下主机、端口、用户名是否完整，然后用测试连接功能验证。
2.3 升级之后先做三件事，能省掉后面一堆排查时间
连接导入完不代表万事大吉，我会按固定顺序做三件事：
第一，测试原来的生产库连接。如果距离上次使用已经比较久，可能数据库密码变过，或者网络策略有调整，先测试最核心的库，确保能连通。
第二，检查“高级”设置里的字符编码和 SSL 选项。MySQL 8.0 对字符集的默认值有变化，Navicat 15 里建议把编码设置保持为自动，不要手动锁定成老项目的utf8，否则新库里的中文数据显示会出现乱码。
第三，验证 SQL 编辑器能正常解析 MySQL 8.0 的新语法。Navicat 11 时代还没完全支持 CTE（公用表表达式）、窗口函数，升级到 15 后这些语法就不会再被误标红。随便打开一个旧脚本，执行一条窗口函数查询，观察是否报语法错误即可。
Navicat 15 之后的版本对 MySQL 8.0 整体适配度很高，不止是认证插件的问题，还体现在可视化建模、数据同步、导入导出这些常用功能上。这也是我推荐升级的另一个理由。
3. 如果不想升级客户端：修改 MySQL 用户认证方式的备选方案
3.1 先查看当前用户使用的是哪个认证插件
有些场景下，Navicat 版本是公司统一装死的，或者客户端涉及多台机器，升级不是一天两天能完成。这时可以在 MySQL 侧把某个用户的认证方式改回mysql_native_password，让老 Navicat 也能连上。
改之前一定要先确认这个用户当前的认证插件是什么。用命令行或者 MySQL Workbench 执行：
SELECT user, host, plugin FROM mysql.user WHERE user = 'root';也可以查全部用户：
SELECT user, host, plugin FROM mysql.user;重点看plugin这一列。如果显示caching_sha2_password，那就说明当前用户用的是新认证；想要兼容老版 Navicat，则需要改掉这个用户。
3.2 ALTER USER 一条命令改到 mysql_native_password
修改单个用户的认证方式，语法如下：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';注意事项在命令本身就能看出来：你要重新指定密码，而且必须加上WITH mysql_native_password，意思就是“这个用户改用老插件认证”。
执行成功后，建议再刷新一下权限，虽然ALTER USER之后一般不需要强制刷新，但养成习惯总是没错的：
FLUSH PRIVILEGES;然后回到 Navicat 11/12，重新测试连接，问题通常就消失了。
3.3 改回老插件的三个风险，看完再决定要不要这么干
改用户认证方式确实快，但我必须把代价说清楚。
第一，mysql_native_password已经是官方眼中的“遗产方案”，MySQL 社区版后续版本已经在逐步收紧对它的默认支持，未来官方彻底禁用只是时间问题。长期依赖它，等于给自己埋了一个以后必踩的坑。
第二，高版本 MySQL 升级时，如果检测到核心用户还在用mysql_native_password，可能会在升级过程中给出兼容性告警，升级 MySQL 大版本时又是一轮折腾。
第三，从安全角度看，SHA1 算法早已不推荐使用。如果你的数据库还暴露在公网，很容易成为扫描工具的重点目标。我的建议是：这招只适合临时救急，解决完眼前问题后，要尽快评估把客户端统一升级到 Navicat 15，然后把用户认证券回caching_sha2_password。
4. 全局默认认证插件与新建用户策略
4.1 修改全局配置：让新创建的用户默认走老插件
有时候你不仅要改现有用户，还得保证后续新建的用户默认就是老插件。这种需求往往是团队里不止一个人用旧版 Navicat，大家都会自己建库建账号，一个个提示太费劲。
可以在 MySQL 配置文件（Linux 下通常是/etc/my.cnf或/etc/mysql/my.cnf，Windows 下是my.ini）的[mysqld]段落下加一行：
[mysqld] default_authentication_plugin = mysql_native_password修改完后需要重启 MySQL 服务才能生效。注意，这个参数只影响“之后新建的用户”，已经存在的用户不会被自动改掉，之前那批用户还是需要用ALTER USER一个个调整。
我个人的使用习惯是：全局配置尽量不动，只在创建用户时显式指定插件。因为全局改掉后，团队里新同事很容易忽略认证方式差异，以后交接和排查问题会更迷茫。
4.2 MySQL 8.0.34 之后的 authentication_policy 要注意
如果你是相对较新的 MySQL 8.0 版本，特别是 8.0.34 及之后的小版本，配置里可能会出现这样的告警：default_authentication_plugin已经标记为废弃，推荐使用新的authentication_policy参数。
新版参数可以这样设置：
[mysqld] authentication_policy = mysql_native_password设置后，新用户默认也会落到mysql_native_password。但因为这个参数在更复杂的认证组合场景下还有扩展用法，我建议动手改之前先用SHOW VARIABLES LIKE 'authentication_policy';查看当前取值，不要照抄网上的配置就完事。
实在不确定时，最稳妥的方法还是走用户级ALTER USER，直接指定插件，绕开全局参数的版本差异。
4.3 新建用户时显式指定插件，比全局配置更可控
新建用户时，完全可以在CREATE USER语句里直接指定认证插件。比如：
CREATE USER 'newuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';或者保持新插件：
CREATE USER 'newuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'your_password';显式指定插件的好处是全局配置无论怎么变，这只用户的行为都是确定的。等团队客户端都升级到 Navicat 15 后，新用户就可以统一用caching_sha2_password，老用户再做一轮ALTER USER切回新插件，整个过程清清楚楚。
5. 连接报错速查与实操避坑记录
5.1 1251 和 2059 一字之差，处理方向完全不同
1251通常意味着“客户端不支持服务器请求的认证协议”。它的处理思路就是升级客户端，或者把用户改成老认证插件。
而2059错误往往显示为：Authentication plugin 'caching_sha2_password' cannot be loaded。这个报错更直白，就是某个客户端组件缺少对caching_sha2_password的实现。有些情况下并不是 Navicat 的问题，而是连接链路里的其他组件太老，比如系统 ODBC 驱动、JDBC 驱动等。
所以看到错误码先别急着改数据库，搞清楚是哪一层报的错，再决定动哪边。
5.2 排查工具与命令速查
我把排查过程中最常用的命令整理成一个速查表，方便你对照操作：
| 场景 | 命令或操作 | 说明 |
|---|---|---|
| 查看用户认证方式 | SELECT user, host, plugin FROM mysql.user; | 确认用户当前用的认证插件 |
| 查看全局默认插件 | SHOW VARIABLES LIKE 'default_authentication_plugin'; | 适用于老版本 MySQL 8.0 排查 |
| 查看新参数取值 | SHOW VARIABLES LIKE 'authentication_policy'; | 8.0.34 之后建议查这个 |
| 临时切换用户认证 | ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password BY 'pwd'; | 兼容老客户端 |
| 切回新认证 | ALTER USER 'user'@'host' IDENTIFIED WITH caching_sha2_password BY 'pwd'; | 客户端升级后长期推荐 |
| 测试连通性 | Navicat“测试连接” | 快捷确认最外层连接是否正常 |
排查时建议先看mysql.user的用户插件，再做客户端对应版本的判断，这样能快速定位是“用户配置问题”还是“客户端版本问题”。
5.3 非 Navicat 场景的同类坑，顺便说一句
这个坑并不仅限于 Navicat。Python 的pymysql、Java 的 JDBC、PHP 的mysqli，在连接 MySQL 8.0 时都可能遇到同样的caching_sha2_password问题。
JDBC 里常见的报错是Public Key Retrieval is not allowed，这是因为caching_sha2_password在非 SSL 连接下需要向服务器请求 RSA 公钥，而 JDBC 驱动默认不允许这么做。解决方式是在连接串里加上allowPublicKeyRetrieval=true，并使用verifyServerCertificate=false。这种问题跟 Navicat 的表现形式不同，但根因都是认证插件变化导致的。
移动端应用如果接的是老库迁移到 MySQL 8.0，也建议先确认所使用的 ORM 框架是否更新了对新认证插件的支持，不然后期线上连不上，排查成本会很高。
最后再分享一点个人习惯
我自己每次连一个陌生数据库时，第一反应不是立刻输密码，而是先查一下它的版本和用户认证方式。用SELECT VERSION();确定 MySQL 大版本，再看mysql.user表确认用户插件。这两个信息拿到手，连接报错的处理方向基本就明确了。
解决caching_sha2_password认证问题的本质，不是“改密码”，而是让客户端和服务器在认证算法上达成一致。升级 Navicat 到 15 是更符合长期利益的选择，改用户认证方式只是临时方案。建议团队里统一客户端版本，并且把数据库用户的认证插件策略写入内部文档，避免每次有人新装环境都重新踩一遍同一堆坑。
