【Navicat连接MySQL】2059错误终极指南：从caching_sha2_password到mysql_native_password的切换实战
1. 为什么Navicat连不上MySQL 8.0？聊聊2059错误的“前世今生”
如果你刚装好最新的MySQL 8.0，兴冲冲地打开Navicat准备连接，结果屏幕上弹出一个“2059 - authentication plugin 'caching_sha2_password'”的错误，心里是不是咯噔一下？别慌，这几乎是每个从MySQL 5.7升级到8.0，或者初次使用8.0的朋友都会踩的“经典大坑”。我当年第一次遇到的时候，也折腾了好一阵子。今天，我就把这个问题的来龙去脉和彻底解决的实战步骤，掰开揉碎了讲给你听，保证你看完就能搞定。
简单来说，这个错误的核心矛盾在于“新”与“旧”的不匹配。MySQL 8.0这个“新家伙”为了提高安全性，默认采用了一种更先进的用户密码认证插件，叫做caching_sha2_password。你可以把它理解成一种更复杂、更安全的“门锁”。而很多我们常用的数据库管理工具，比如一些旧版本的Navicat、Workbench，或者一些通过传统驱动连接的程序，它们手里还拿着开老式“门锁”（mysql_native_password）的“钥匙”。新锁配旧钥匙，当然就打不开了，于是2059错误就出现了。
这其实不能怪Navicat“落后”，也不能说MySQL“激进”。本质上，这是技术升级过程中必然出现的“阵痛期”。caching_sha2_password插件在防止密码被窃听、支持SSL加密传输等方面确实更强，是未来的方向。但很多客户端软件和驱动库的更新需要时间。所以，在我们日常开发、运维的当下，最直接、最稳妥的解决方案，就是暂时把MySQL用户的“门锁”从新的换回旧的、大家都认识的mysql_native_password。别担心，这并不意味着安全性的大幅倒退，在绝大多数内部开发、测试和生产环境中，mysql_native_password仍然是足够安全可靠的选择。
所以，解决这个问题的思路非常清晰：找到MySQL里那个用新式锁（caching_sha2_password）的用户，给他换一把旧式锁（mysql_native_password）。整个过程完全在MySQL服务器端操作，不需要你重装MySQL，也不需要你降级Navicat。接下来，我们就手把手进入实战环节。
2. 实战第一步：打开终端，与MySQL“对话”
要修改MySQL的用户设置，我们必须进入MySQL的命令行环境。别被“命令行”吓到，其实就像是用特定的语言和MySQL服务器聊聊天，告诉它我们想做什么。这里有几个前提需要你先确认好：
首先，确保你的MySQL服务正在运行。在Windows上，你可以去“服务”里找找“MySQL80”或者类似名称的服务，看看状态是不是“正在运行”。在Mac或Linux上，可以在终端里输入sudo systemctl status mysql或者ps aux | grep mysql来确认。
其次，你需要知道安装MySQL时设置的root用户密码。如果忘了，网上有重置密码的教程，这里我们先假设你知道密码。
好了，我们打开终端（Windows叫命令提示符CMD或PowerShell，Mac/Linux就是Terminal）。连接MySQL服务器的命令长这样：
mysql -u root -p敲下回车后，系统会提示你输入密码。注意，这里输入密码时，光标是不会移动也不显示星号的，这是正常的安全设计，你只管正确输入然后回车就行。如果密码正确，你会看到提示符变成了mysql>，恭喜，你已经成功进入了MySQL的“指挥中心”！如果提示“Access denied”，请检查用户名和密码是否正确。
进入之后，我建议先做两件事，算是“战前侦察”。第一，看看当前MySQL默认的认证插件是什么。输入以下命令：
SHOW VARIABLES LIKE 'default_authentication_plugin';不出意外，你会看到结果里Value那一列显示着caching_sha2_password。这验证了我们之前的判断：MySQL 8.0默认就是用这个新插件。
光看默认设置还不够，我们得揪出到底是哪个具体的用户在用这个插件导致Navicat连不上。通常这个“罪魁祸首”就是root用户，尤其是允许从任何主机（'%'）连接的root用户。我们来查看一下所有用户的认证插件情况：
SELECT host, user, plugin FROM mysql.user;这条命令会列出MySQL里所有用户账户，以及他们对应的登录主机和使用的认证插件。你会在结果表格里仔细寻找user列为root，并且plugin列为caching_sha2_password的那一行。特别留意host列：localhost表示只能从本机连接，%表示可以从任何主机连接。如果你用Navicat从另一台电脑连接，那么就需要修改host为%的那个root用户。如果root用户只有localhost，但你却想远程连接，那可能还需要先创建一个允许远程连接的用户，或者修改root用户的host。不过我们今天聚焦解决插件问题，假设你已经有了一个host为%的root用户。
3. 核心操作：给用户换上“老钥匙”（mysql_native_password）
侦察完毕，目标锁定，现在开始执行最关键的一步——修改用户的认证插件。这里我们要用到ALTER USER这个SQL命令，它的威力很大，可以修改用户的很多属性，其中就包括认证插件和密码。
假设我们要修改的是可以从任何主机连接的root用户（即'root'@'%'），并且想将它的密码设置为MyNewPass123!（请务必换成你自己想用的强密码），那么命令如下：
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'MyNewPass123!';让我拆解一下这个命令：
ALTER USER：声明要修改一个用户。'root'@'%'：指定要修改的用户名和主机。单引号不能少。如果你要改的是localhost的root，就写成'root'@'localhost'。IDENTIFIED WITH mysql_native_password：核心部分，意思是“使用mysql_native_password插件进行身份认证”。BY 'MyNewPass123!'：在修改插件的同时，为该用户设置一个新密码。如果你不想改密码，只想换插件，理论上可以沿用旧密码，但强烈建议借此机会设置一个强密码。
执行这条命令后，如果看到Query OK, 0 rows affected (0.02 sec)这样的提示，就说明修改成功了。MySQL没有返回具体行数变化是正常的，因为它修改的是系统权限表里的元数据。
修改完，我们立刻再查一下确认成果：
SELECT host, user, plugin FROM mysql.user WHERE user = 'root';这次你应该能看到，对应root用户的那一行，plugin列已经变成了mysql_native_password。这就好比我们已经成功地把用户家的“新式智能锁”换成了“传统机械锁”。
但是，这里有一个至关重要的步骤，90%的新手都会忘记，导致改了还是连不上！那就是：让MySQL服务器重新加载权限表，使刚才的修改立即生效。你只是改了“账本”，还没告诉“门卫”呢。执行这个命令：
FLUSH PRIVILEGES;看到Query OK就表示权限刷新成功了。好了，MySQL服务器端的工作全部完成。你可以输入exit;或者\q命令退出MySQL命令行。
4. 不只是Root：处理其他用户与一劳永逸的配置
解决了root用户，你的Navicat应该就能连上了。但我们的实战不能止步于此。想象一下，你开发的应用使用了一个专门的数据库用户，比如叫myappuser，如果这个用户也是在MySQL 8.0之后创建的，默认也会使用caching_sha2_password插件。当你的应用程序（比如一个Python脚本、一个Java项目）使用旧的MySQL连接驱动去连接时，同样会遭遇类似的“2059”错误。
所以，你需要检查并修改所有需要被旧版客户端访问的用户。方法同上，只需替换用户名和主机即可。例如：
ALTER USER 'myappuser'@'%' IDENTIFIED WITH mysql_native_password BY 'AppUserStrongPassword!'; FLUSH PRIVILEGES;难道每次新建用户都要手动改一次插件吗？这太麻烦了。有没有一劳永逸的办法？有的，那就是直接修改MySQL的默认认证插件，让以后新创建的用户，默认就用mysql_native_password。这需要修改MySQL的配置文件。
MySQL的配置文件通常是my.cnf（Linux/Mac）或my.ini（Windows）。它的位置因系统而异，常见位置有/etc/mysql/my.cnf、/etc/my.cnf，或者在Windows的MySQL安装目录下。找到这个文件，用文本编辑器（如Notepad++、VS Code，不要用Windows自带的记事本，可能编码有问题）打开它。
在[mysqld]这个配置段下面，添加一行：
[mysqld] default_authentication_plugin=mysql_native_password保存文件，然后重启MySQL服务。重启后，之后任何新创建的账户，默认都会使用mysql_native_password插件了。请注意：这个修改不会影响已经存在的用户。已经存在的root用户，如果之前没改过，还是caching_sha2_password，需要你用前面的ALTER USER命令单独修改。
重启服务的方法：
- Windows：在“服务”管理器中找到MySQL服务，右键选择“重启”。或者用管理员命令行
net stop MySQL80然后net start MySQL80（服务名可能不同）。 - Linux (Systemd)：
sudo systemctl restart mysql - Mac (Homebrew)：
brew services restart mysql
5. 回到Navicat：测试连接与高级配置
服务器端搞定后，我们回到Navicat，进行最终的连接测试。打开Navicat，点击“连接” -> “MySQL”。在弹出的连接设置窗口里，常规标签页需要填写：
- 连接名：随便起个你能识别的名字，比如“本地MySQL8”。
- 主机：如果是连本机，就填
localhost或127.0.0.1；如果是远程连接，就填服务器的IP地址。 - 端口：默认是
3306，如果没改过就保持默认。 - 用户名：
root（或者你修改过的其他用户名）。 - 密码：这里要填你刚才在
ALTER USER命令中BY后面设置的新密码！很多朋友在这里填了旧的密码，导致连接失败，又绕回原点。
填写完毕后，先别急着点“确定”。我强烈建议你点一下“测试连接”按钮。如果弹出“连接成功”的提示，那么万事大吉！如果还是失败，请仔细检查：
- 主机/IP地址是否正确？
- 端口是否被防火墙阻挡？（尤其是远程连接时，需要在服务器安全组或防火墙放行3306端口）
- 用户名和主机标识是否匹配？（你改的是
'root'@'%'，但Navicat里用root连localhost，这可能不匹配） - 密码是否输入了修改后的新密码？
- MySQL服务是否已重启（如果你改了配置文件）？
测试成功后再点“确定”保存连接。双击这个新连接，你应该就能顺利看到数据库列表了。
有时候，即使修改了插件，一些非常旧的客户端可能还需要一点“帮助”。在Navicat的高级标签页里，有一个“连接属性”或“高级”设置区域。你可以尝试添加一个连接参数：default_authentication_plugin=mysql_native_password。这相当于在连接时再次明确告诉客户端：“请使用旧式插件进行握手”。虽然服务器端已经改了，但加上这个参数有时能解决一些驱动层面的兼容性问题。
6. 深入理解：两种插件有何不同？未来该怎么办？
问题解决了，但我们不能只停留在“知其然”，最好也“知其所以然”。mysql_native_password和caching_sha2_password到底有什么区别？
mysql_native_password是MySQL长期以来使用的传统认证方式。它使用SHA1哈希算法对密码进行处理，整个认证过程相对简单。而caching_sha2_password是MySQL 8.0引入的，它使用更安全的SHA256算法，并且支持更先进的密码交换协议。它的“caching”（缓存）部分指的是，它会在内存中缓存成功的认证信息，对于频繁的连接可以提升性能。更重要的是，它强制要求使用SSL/TLS加密连接，或者在非加密连接下使用RSA密钥对来交换密码，这极大地增强了密码在传输过程中的安全性，防止被网络嗅探。
所以，从安全角度看，caching_sha2_password无疑是更优的选择。那么，我们把它改回去，是不是在“开倒车”呢？在特定场景下，可以这么说。但技术决策永远是在安全、兼容性和成本之间做权衡。如果你的环境是安全的内部网络，或者你能够确保所有客户端都支持新插件，那么当然应该使用caching_sha2_password。
未来的正确姿势是什么？升级你的客户端！新版本的Navicat（我记得大概从12版本开始？）、MySQL Workbench 8.0、以及各语言最新的MySQL连接驱动（如Python的mysql-connector-python， Java的mysql-connector-java8.0+）都已经支持了caching_sha2_password插件。所以，长远的解决方案不是一直“降级”服务器，而是将你的客户端工具和程序驱动更新到支持新认证协议的版本。当你确保所有访问MySQL的终端都升级到位后，就可以考虑将用户的认证插件重新改回caching_sha2_password，并配置好SSL证书，享受更高级别的安全保护。
7. 避坑指南：我踩过的那些雷
最后，分享几个我在帮别人解决这个问题时，经常遇到的“坑”，希望能帮你节省时间。
第一个坑：改错了用户。仔细看SELECT host, user, plugin FROM mysql.user;的结果。你可能在本地用root登录，但MySQL里存在'root'@'localhost'和'root'@'%'两个用户。如果你用Navicat连接的是localhost，却只改了'root'@'%'，那当然没用。你需要修改的是与你连接方式（主机地址）匹配的那个用户。
第二个坑：忘记刷新权限。就像前面强调的，ALTER USER之后必须跟一句FLUSH PRIVILEGES;，否则修改可能不会立即生效，你会怀疑人生。
第三个坑：密码复杂性。MySQL 8.0默认启用了密码强度验证插件。如果你设置的密码太简单，ALTER USER命令可能会失败，提示“Your password does not satisfy the current policy requirements”。这时，要么设置一个包含大小写字母、数字、特殊符号的强密码，要么临时修改密码策略（通过SET GLOBAL validate_password.policy=LOW;，但生产环境不推荐降低策略）。
第四个坑：配置文件修改不生效。修改了my.cnf后，一定要重启MySQL服务。并且要确认你修改的是MySQL服务器真正读取的那个配置文件。有时系统里有多个配置文件，可以通过mysql --help | grep "my.cnf"命令查看MySQL读取配置文件的顺序。
第五个坑：防火墙和端口。所有操作都对了，但Navicat还是连不上，尤其是远程连接。请务必检查服务器防火墙是否开放了3306端口，云服务器（如阿里云、腾讯云）还需要检查安全组的入站规则。
遇到问题别着急，按照“先验证服务、再核对用户、三查密码权限、四看网络端口”的顺序一步步排查，总能找到原因。数据库连接这类问题，细节决定成败。希望这篇超详细的指南，能帮你彻底扫清Navicat连接MySQL 8.0的道路。