1. 报错现场Navicat 连接 MySQL 8.x 时突然罢工如果你最近刚装好 MySQL 8.x或者接手了一个用了新版 MySQL 的项目打开 Navicat 点连接时大概率会撞上下面这行红字2059 - authentication plugin caching_sha2_password cannot be loaded:翻译成人话就是MySQL 服务端说“我用的密码认证方式你 Navicat 不支持咱俩谈不拢”。第一次遇到的朋友很容易懵明明账号密码没错、端口也通、服务也在跑为什么就是连不上先说结论这跟账号密码无关纯粹是 MySQL 8.0 开始把默认的身份认证插件从mysql_native_password换成了caching_sha2_password而你本地的 Navicat 版本太老只认旧插件。服务端换了新锁客户端还在用旧钥匙自然插不进去。这个报错我在好几个环境里都真实遇到过——本机连、远程连、Docker 起的 MySQL 都出现过。这篇文章就把三种主流的解决思路完整写一遍包括底层原理、操作步骤、踩坑点以及什么情况下选哪种方案最合适。2. 为什么会有这个错误认证插件切换的前因后果2.1 MySQL 8.0 的默认认证机制变化MySQL 8.0 发布时官方把默认的身份认证插件从mysql_native_password换成了caching_sha2_password。这俩都是用来验证客户端连接时密码是否正确的东西但实现方式差异很大。mysql_native_password是 MySQL 5.x 时代的老方案基于 SHA1 做密码散列。它的优点是实现简单、兼容性好几乎所有老客户端都支持缺点是整个认证过程的安全强度一般如果连接通道没有加密密码散列存在被截获后离线爆破的风险。caching_sha2_password基于 SHA256 密码散列认证流程更复杂安全强度更高。它还在服务端加了一层缓存机制第一次认证成功后后续短时间内的重复连接可以直接走缓存验证性能上比逐次全量计算要好。听起来是升级但代价就是老客户端不认识它。官方在 MySQL 8.0 里把默认插件改成caching_sha2_password不是拍脑袋。当时 Oracle 的公告里也说得明白老的 native password 认证方式已经跟不上安全要求了新版本必须推动整个生态往强认证迁移。于是凡是 8.0 之后新建的 MySQL 用户默认都挂在这个新插件上。2.2 为什么 Navicat 会翻车Navicat 其实是支持 MySQL 连接的老牌工具但它的 Windows 老版本比如 11.x、12.x 早期版本内置的 MySQL 客户端库还停留在支持mysql_native_password的阶段。服务端换成了caching_sha2_password客户端这边没有对应的实现握手时服务端下发插件名称客户端尝试加载对应的认证插件发现没有于是直接抛出 2059。这就像两个人在对暗号服务端说“我用的是新暗号”客户端翻遍自己口袋只带了旧暗号谈判直接破裂。注意这个报错不是账号密码输错了也不是防火墙拦截更不是 MySQL 服务没启动。你换成老的 MySQL 5.7 连接同样的账密参数一点毛病没有。2.3 这个错误的常见出现环境我统计了一下自己遇到和帮别人排查过的场景大概是这几类出现场景典型原因本机新装 MySQL 8.x用 Navicat 连新建用户默认用新插件从 MySQL 5.7 迁移数据到 8.x建了新库新用户迁移过程中用户被重建走了默认插件Docker 拉取 mysql:8 镜像起服务镜像内默认配置就是新插件远程服务器 MySQL 8.x本地 Navicat 连接本地 Navicat 版本过老使用某些管理面板创建的 MySQL 8 实例面板创建用户时没指定旧插件清楚了根因接下来就看怎么选择解决路径。3. 解决方案一把用户的认证插件改回 mysql_native_password最常用这个方案的思路很简单既然服务端换了新锁客户端又太老开不了那就把锁换回旧款。对本地开发环境、测试环境来说完全够用操作最快且不需要升级客户端。3.1 具体操作步骤用命令行连接 MySQL比如用mysql -u root -p然后执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;如果 root 用户还涉及远程连接localhost要改成%或者对应的主机段ALTER USER root% IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;如果你想先看看到底哪个用户挂了什么插件可以查一下SELECT user, host, plugin FROM mysql.user;正常情况下输出里会看到---------------------------------------------------- | user | host | plugin | ---------------------------------------------------- | root | localhost | caching_sha2_password | | mysql.sys | localhost | caching_sha2_password | ----------------------------------------------------你把 root 行的 plugin 改成mysql_native_passwordNavicat 就能恢复正常连接。3.2 为什么执行完后 Navicat 立刻能连因为 Navicat 握手时服务端会告诉它“这个用户用的是mysql_native_password”客户端发现自己带了这个插件直接按老流程走密码验证一次通过。整个过程不需要重启 MySQLFLUSH PRIVILEGES只是刷新权限表的缓存让改动立即生效。3.3 这个方案有什么弊端先说清楚改回旧插件本质上是“向下兼容”安全强度确实不如caching_sha2_password。如果你是公网环境、生产库、或者合规要求比较严的项目建议优先考虑升级客户端而不是让服务端降级。另外注意如果你后续用 SQL 重置了这个用户的密码插件不会自动变回去。比如你执行ALTER USER rootlocalhost IDENTIFIED BY 新密码;这条语句在 MySQL 8.0 里会按照default_authentication_plugin的配置重新指定插件如果全局默认还是caching_sha2_password那你的用户又会被切回新插件。遇到“刚才还好好的改完密码又 2059 了”的情况多半就是这原因。所以改密时得显式带插件名ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 新密码;3.4 多条命令的完整操作演示假设你 MySQL 装在本地root 密码是123456想彻底解决 Navicat 连接问题操作是这样的mysql -uroot -p # 输入密码登录后依次执行 ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 123456; FLUSH PRIVILEGES; # 验证 SELECT user, host, plugin FROM mysql.user WHERE user root;输出结果应该变成---------------------------------------- | user | host | plugin | ---------------------------------------- | root | localhost | mysql_native_password | ----------------------------------------这时候再打开 Navicat原来的 2059 就不会出现了。这个方法我用的频率最高因为它只影响目标用户不会动全局配置风险可控。4. 解决方案二升级 Navicat 到支持新插件的版本更符合长期利益如果你连接的是正式环境、生产数据库或者你根本不想动服务端任何配置那么升级客户端才是正确方向。Navicat 在 15.x 之后的版本里已经加入了对caching_sha2_password的支持。4.1 为什么升级客户端是更优解MySQL 官方在 8.0 里默认新插件并承诺后续版本会持续强化这套认证机制。你如果一直用老 Navicat每连一个新库都要去改服务端用户插件长期看维护成本很高。而且服务端用户插件改成旧方案后一些新版 MySQL 的特性比如更严格的密码校验策略、双密码支持等在使用时可能受限。把客户端升级到支持新插件的版本相当于一步到位以后建任何新用户都用默认配置不用再操心兼容性。4.2 具体怎么确认你的 Navicat 是否支持打开 Navicat 的“关于”看版本号。如果你当前是 11.x、12.x 或者 13 早期版本大概率不支持新插件。直接去官网下载最新版本安装后替换即可。升级完连接还是失败的话可以检查一下是不是配置文件残留或者连接串里指定了旧协议。Navicat 的连接设置里“高级”选项卡如果有“使用旧版加密”之类的选项取消勾选。小技巧升级前先备份一下 Navicat 的连接配置位置一般在“工具 - 选项 - 配置”里可以导出。不然重装后一堆连接信息手动重建很烦。4.3 这条路的坑点升级 Navicat 后连老 MySQL 5.7 实例通常没问题它向下兼容旧插件。但如果你的 Navicat 是破解版或者从非官方渠道下载的升级前记得先导出连接配置升级完如果授权文件失效连接配置也会受牵连。另外升级不代表服务端原来已经改成旧插件的用户会自动变回新插件你需要根据自己的需要决定是否再执行一次切换。5. 解决方案三直接改 MySQL 全局默认认证插件一劳永逸前面两个方案是针对单用户的如果想让这台 MySQL 之后新建的所有用户默认都用mysql_native_password可以修改服务端配置。5.1 修改 my.cnf / my.ini在 MySQL 配置文件里的[mysqld]段落下加一行default_authentication_pluginmysql_native_passwordLinux 下配置文件一般在/etc/mysql/mysql.conf.d/mysqld.cnf或者/etc/my.cnfWindows 下在 MySQL 的安装目录里找my.ini。改完重启 MySQLsystemctl restart mysql或者 Windows 服务里重启 MySQL 服务。重启后新建用户默认就会用旧插件CREATE USER test_userlocalhost IDENTIFIED BY 123456; SELECT user, host, plugin FROM mysql.user WHERE user test_user;你会看到新用户已经挂上了mysql_native_password。5.2 这个方案适合什么场景只推荐在本地开发环境、内网测试环境使用。生产环境不要说改全局默认连单用户降级插件都要走审批最好还是保持默认新插件 升级客户端。另外一个很常见的变体你用的是云数据库 RDS控制台登录时没有权限改配置文件这种情况就别想着改全局了老老实实按方案一走单用户修改或者升级客户端。5.3 一个容易被人忽略的细节MySQL 8.0.34 之后官方其实已经将mysql_native_password标记为废弃deprecated并且从 8.4 版本开始默认禁用这个插件。如果你用的是非常新的 MySQL 版本执行ALTER USER ... IDENTIFIED WITH mysql_native_password可能会直接报错提示插件不可用。这种情况下你就需要显式启用旧插件在配置文件里加[mysqld] mysql_native_passwordON然后再执行 ALTER USER 语句。说实话这条路已经是逆着官方方向走了能用但不够优雅。我的建议是尽量走升级 Navicat 的路子省心。6. 权限表视角root 之外的其他用户遇到 2059 怎么处理日常开发中很多项目不会用 root 连接数据库而是由 DBA 创建专用账号。这些专用账号如果也遇到 2059处理思路一样但需要额外注意权限范围。6.1 只改应用账号不动 root应用账号一般长这样CREATE USER app_user% IDENTIFIED BY AppPassword123; GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO app_user%;如果这个账号连不上执行ALTER USER app_user% IDENTIFIED WITH mysql_native_password BY AppPassword123; FLUSH PRIVILEGES;只改这个账号不影响 root 和其他用户。6.2 区分 localhost / % / 具体 IPMySQL 的用户是“用户名 主机”二元组app_userlocalhost和app_user%是两个完全独立的账号。改错主机段连接还是报错。排查的时候先执行SELECT user, host, plugin FROM mysql.user WHERE user app_user;看清楚连接来源对应的 host 是哪个再执行对应的 ALTER。比如你在公司内网用 192.168.1.50 连接但账号只建了app_user%那就要改%那条。6.3 密码策略可能成为隐形门槛MySQL 8.0 默认启用了密码校验组件太简单的密码比如123456在建用户时直接会被拒掉。但你要是用IDENTIFIED WITH mysql_native_password BY 123456这种写法部分版本也会触发密码强度校验失败。遇到ERROR 1819 (HY000): Your password does not satisfy the current policy requirements时要么把密码改复杂要么临时调低校验等级SET GLOBAL validate_password.policy LOW; SET GLOBAL validate_password.length 6;需要说明的是这是全局设置测试环境可以用生产环境不建议动。7. 生产环境迁移的注意点从 5.7 升到 8.x 时的 2059MySQL 5.7 迁到 8.x 是很多团队都会经历的。数据迁移本身有官方工具可以操作但这中间最容易忽略的就是认证插件差异尤其在代码里、配置里、快捷连接工具里全部都要跟着适配。7.1 迁移后 2059 为什么出现的概率极高原因很简单老库里的所有账号都是mysql_native_password迁移到新库后如果通过工具重建账号、导入用户表新的 MySQL 8.x 默认插件会把新建的用户设置成caching_sha2_password。如果你的中间件、定时任务、BI 工具用的驱动还是老版本连上就报 2059。更麻烦的是有些迁移工具只迁移数据不迁移用户迁移完你需要手动重建所有业务账号重建时没显式指定插件默认就走新插件。7.2 迁移时一次性把所有账号改成旧插件你可以用 SQL 动态生成 ALTER 语句一条条执行。比如在旧库导出用户清单然后拼接语句SELECT CONCAT(ALTER USER , user, , host, IDENTIFIED WITH mysql_native_password BY 密码;) FROM mysql.user WHERE plugin caching_sha2_password AND user NOT IN (mysql.sys, mysql.session, mysql.infoschema);把输出结果复制到新库执行。注意密码部分需要手动补全这个 SQL 只是方便你快速生成语句。改完后不需要重启 MySQL。7.3 应用连接串里的参数适配如果你的应用代码用 JDBC 连接 MySQL 8.x且服务端用户还是新插件那么驱动版本也很关键。使用老版本驱动比如 mysql-connector-java 5.1.x连接时即使服务端没有强制要求新插件也可能出现类似报错。升级驱动到 8.0.x 之后连接串可以加上jdbc:mysql://localhost:3306/db?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue这个参数只有在连接方式不支持 SSL 时才需要。如果你的服务器开启了 SSL那么这一行不写也没问题。7.4 迁移后验证清单迁移完别急着收工我习惯按这个清单过一遍用命令行本地登录确认账号密码可用用 Navicat 分别连接 localhost 和远程地址用应用代码跑一遍核心接口检查慢查询日志里有没有认证失败的记录。8. Docker 部署 MySQL 8.x 时 2059 的处理细节Docker 跑 MySQL 是另一类高频场景处理思路略有不同因为容器环境里改配置、改用户的路子都受镜像机制影响。8.1 容器内的快速解决方式先用 docker exec 进入容器docker exec -it mysql8 mysql -uroot -p然后执行ALTER USER root% IDENTIFIED WITH mysql_native_password BY 你的密码; FLUSH PRIVILEGES;这个方案和前面方案一相同但注意容器重启后 MySQL 服务会重新启动用户表是持久化在数据卷里的所以改一次就长期有效不需要每次都改。8.2 通过环境变量直接创建旧插件用户最省事如果你还没创建容器可以在docker run时挂一个初始化脚本docker run -d \ --name mysql8 \ -e MYSQL_ROOT_PASSWORDrootpass \ -v /opt/mysql-init:/docker-entrypoint-initdb.d \ -p 3306:3306 \ mysql:8在/opt/mysql-init/init.sql里写入ALTER USER root% IDENTIFIED WITH mysql_native_password BY rootpass; FLUSH PRIVILEGES;容器首次初始化的时候会自动执行这个脚本之后启动就默认带旧插件。8.3 容器场景下升级客户端反而是更干净的路有的人图省事直接改容器内 MySQL 配置挂载自定义 my.cnf 把默认插件设为旧插件这确实能解决但容器重建时你很容易忘了这回事而且这个配置本身就是逆着官方默认方向走的。毕竟是本地开发环境怎么方便怎么来但如果你这个容器是为了模拟生产环境那我不建议你改配置保持默认新插件然后用新版 Navicat 连接才是最贴合真实线上环境的做法。9. 我的选择建议与踩坑总结9.1 三种方案怎么选场景推荐方案原因本地开发、随便连连方案一改用户插件最快影响面最小正式环境、长期使用方案二升级 Navicat服务端保持强认证客户端适配新标准测试环境新建用户量大方案三改全局默认插件省得每个用户单独改Docker 一次性起服务方案一或初始化脚本起完就能连脚本可复用生产迁移 5.7 - 8.x方案二 升级驱动保证线上安全等级不下滑9.2 我踩过的三个真实坑写出来给大家避开第一个坑只改了 localhost 的 root忘了 Navicat 用的是远程地址连接。Navicat 连接配置里如果主机填的是127.0.0.1或局域网 IPMySQL 匹配的是root%或root127.0.0.1而不是rootlocalhost。结果就是明明执行了 ALTERNavicat 还是报 2059瞎折腾半小时。第二个坑密码改完后插件又变回去了。我之前给测试环境改过 root 用户插件后来同事重置了一次密码用的语句没带插件名结果 MySQL 8.0 默认又把插件切回caching_sha2_passwordNavicat 再次报 2059。所以团队里如果有人会操作数据库最好在文档里注明“改密必须带 WITH mysql_native_password”。第三个坑升级 Navicat 后连接串里的端口问题。有次升级完旧版本里保存的连接默认走 3306 没问题但新版本里如果之前选过 SSH 隧道升级后部分配置会重置。连接超时的时候别急着怀疑服务端重新检查一下连接配置的端口和 SSH 开关。9.3 日常连接 MySQL 8.x 的预防思路与其每次被 2059 搞一次不如提前做点预防工作统一客户端版本团队内部约定 Navicat 最低版本避免每个人报错原因各不相同。建用户时就确定插件创建账号时顺手把WITH mysql_native_password写进去后续省事。配置管理文档化任何 ALTER USER、CREATE USER 操作都留痕尤其是插件相关的变更。定期检查用户插件矩阵每月执行一次上面提到的SELECT user, host, plugin FROM mysql.user发现意外的旧插件用户及时评估切换。我个人的体会是这个错误本身不复杂但因为它牵涉到客户端、服务端、账号权限、配置持久化几个层面排查链路长最容易在细节上翻车。只要把插件原理和修改路径搞清楚它也就是顺手一条 SQL 的事。