是小鬏鬏啊ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded，我第一次遇到这个报错是在帮同事处理一台 MySQL 8.0 开发库的时候。当时他执行 ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';，结果直接弹了这么一行红字，整个人都有点懵。后来我仔细排查了一遍才发现，这根本不是密码写错了，也不是权限不够，而是 MySQL 8.0 默认不再加载 mysql_native_password 这个认证插件导致的。这篇文章就把我排查和解决这个问题的完整过程写出来，包括原理、复现步骤、三种修复方案、以及最容易踩的坑，希望能帮你少走弯路。
1. 先搞清楚 ERROR 1524 到底在说什么
1.1 错误信息的字面含义
这条报错的完整格式是：
text复制ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
拆开看，1524 是 MySQL 自定义的错误码，HY000 是 ODBC 标准的通用错误类别，真正有用的信息在最后一句：Plugin 'mysql_native_password' is not loaded，意思是 MySQL 服务器当前没有加载名为 mysql_native_password 的认证插件。
这个插件是做什么的？它是 MySQL 5.x 时代默认的密码认证插件，负责把客户端提交的密码用 SHA1 算法做两次哈希，然后和 mysql.user 表里存的 authentication_string 做比对。MySQL 8.0 开始默认换成了 caching_sha2_password，mysql_native_password 虽然还在，但很多发行版的默认配置里不再加载它。于是一旦你的操作显式或隐式地引用了这个插件，服务器就报 1524。
1.2 哪些操作会触发这个报错
根据我自己的复现，下面几种操作都会踩到这个坑：
- 执行
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';，手动指定用这个插件改密码。 - 某些旧版客户端或图形化工具（比如老版本的 Navicat、DBeaver）连接时，在握手阶段主动请求
mysql_native_password，而服务器没加载它，于是连接失败或后续修改用户时报 1524。 - 从 MySQL 5.7 迁移数据或配置到 8.0 时，SQL 脚本里带有
IDENTIFIED WITH mysql_native_password。 - 使用
--skip-grant-tables跳过权限表启动后，执行FLUSH PRIVILEGES或修改用户，也可能触发相关提示（后面专门说）。
值得注意的是，报错不一定发生在登录环节。有时你能正常登录，但一改密码就报错，原因就是当前会话或当前用户依赖的认证插件在服务器上不可用。
1.3 为什么 8.0 默认不加载它
MySQL 8.0 发布时，官方把默认认证插件从 mysql_native_password 换成了 caching_sha2_password。后者的安全性更高，使用 SHA256 加密，还支持服务端缓存，性能也不差。官方虽然没有立刻删除 mysql_native_password，但在 8.0 的某些版本和某些发行版中，默认不启用它。
我在一台 CentOS 上用官方 Yum 源装的 MySQL 8.0.33，执行 SHOW PLUGINS;，列表里根本没有 mysql_native_password 这一行。但我在另一台用源码编译的 8.0.36 上，同一命令却能看到它。这就有意思了：同样是 8.0，行为可能不一样。原因在于编译选项和配置文件，有的发行版把插件编译成了动态库 .so 文件，但默认没有 LOAD，需要手动加载。
提示：判断服务器是否支持某个插件，最直接的方法是查看
SHOW PLUGINS;输出，或者查information_schema.plugins表。不要凭 MySQL 版本号猜测。
1.4 其他高频相关错误速查
排查过程中我发现，和 mysql_native_password 相关的问题往往成串出现，列几个常见的供你对照：
| 错误码 | 典型信息 | 常见原因 |
|---|---|---|
| 1524 | Plugin 'mysql_native_password' is not loaded | 插件未加载，或用户指定了该插件但服务器不支持 |
| 2059 | Authentication plugin 'mysql_native_password' cannot be loaded | 客户端加载不到插件，通常发生在旧版客户端 |
| 2002 | Can't connect to local MySQL server through socket '/tmp/mysql.sock' | 服务未启动，或 socket 文件路径不对 |
| 1396 | Operation ALTER USER failed for 'root'@'localhost' | 用户不存在，或修改的 host 与实际不匹配 |
| 1290 | MySQL server is running with the --skip-grant-tables | 服务器跳过权限表，不能直接执行写权限操作 |
如果你是在改密码时遇到 1524，大概率就是认证插件的问题；如果是在连接时报 2059，那往往是客户端的问题，不是服务器端。两者修法不同，先分清你在哪一步报错。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 彻底复现：从报错到定位的完整排查链路
2.1 我的复现环境
- 操作系统：CentOS 7.9
- MySQL 版本：8.0.33（官方 Yum 仓库安装）
- 客户端：mysql 8.0.33 自带 CLI
- 连接方式：本机 socket
2.2 复现步骤与每一步的实际输出
第一步，用 root 登录：
bash复制mysql -uroot -p
输入密码后能正常进入。执行：
sql复制SELECT user, host, plugin FROM mysql.user;
输出里 root 对应的 plugin 是 caching_sha2_password，这很正常。
第二步，尝试修改 root 密码认证插件：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';
此时报错：
text复制ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
第三步，检查插件是否加载：
sql复制SHOW PLUGINS;
在完整的插件列表里搜索 mysql_native_password，没有输出行。再用精确查询：
sql复制SELECT plugin_name, plugin_status, plugin_type
FROM information_schema.plugins
WHERE plugin_name = 'mysql_native_password';
结果为空集。到这里实锤了：服务器没有加载该插件。
我顺手确认了一下插件动态库文件是否存在：
bash复制find /usr/lib64/mysql/plugin/ -name '*mysql_native_password*'
输出显示 /usr/lib64/mysql/plugin/mysql_native_password.so 文件存在。这就说明，插件文件是有的，只是没有加载。后续修复的核心思路就变成了：要么加载这个 .so，要么不再引用这个插件。
2.3 排查链路的通用化：三步定位法
如果你也遇到类似报错，不要急着百度搜命令，按下面三条线走，基本能定位 90% 的问题：
- 确认报错发生在连接阶段还是 SQL 执行阶段。连接阶段报错，优先查客户端版本和服务端认证插件兼容性；SQL 执行阶段报错，优先查服务器端插件加载状态。
- 执行
SHOW PLUGINS;或查information_schema.plugins，确认mysql_native_password是否存在。 - 查看插件动态库文件是否存在，确认是"没编译"还是"没加载"。
其中第二步和第三步特别关键。如果插件文件存在但没加载，可以直接 INSTALL PLUGIN；如果文件都不存在，则只能修改账号认证方式，或者重装对应插件包，再或者换用官方 RPM/包管理工具补装。
3. 三种可落地的修复方案及选型建议
根据你当前系统的状态和约束条件，下面三种方案各有适用场景。我按推荐顺序展开。
3.1 方案一：直接安装插件（推荐，最快）
如果插件 .so 文件存在，最直接的办法就是手动加载它：
sql复制INSTALL PLUGIN mysql_native_password SONAME 'mysql_native_password.so';
执行后可以用 SHOW PLUGINS; 验证是否出现 mysql_native_password。如果成功，再执行原先的 ALTER USER 就不会报 1524 了。
不过这里有个关键问题：INSTALL PLUGIN 需要 INSERT 权限（通常 root 有），而且它会修改 MySQL 的系统表。我之前在一台机器上执行时遇到过权限不足，所以建议用 root 或具有 SYSTEM_VARIABLES_ADMIN、INSERT 权限的账号执行。
另外，动态安装的插件在 MySQL 重启后是否自动加载，取决于你是否写入了配置文件。如果希望永久生效，在 [mysqld] 段加一行：
ini复制mysql_native_password=ON
或者更通用的写法：
ini复制plugin-load-add=mysql_native_password.so
然后重启 MySQL。注意，不同版本的配置项名称可能有差异，部分 8.0 版本支持 mysql_native_password=ON，有些则只认 plugin-load-add。我在 8.0.33 上用 mysql_native_password=ON 实测有效，但在另一个 8.0.20 上却报"变量不存在"，改用 plugin-load-add 才成功。
3.2 方案二：修改账号认证方式为 caching_sha2_password（长期更优）
如果你的业务并不依赖 mysql_native_password，最稳妥的做法是别去加载旧插件，直接把账号的认证方式改成 8.0 默认的 caching_sha2_password。
但是这里有个鸡生蛋的问题：执行 ALTER USER ... IDENTIFIED WITH caching_sha2_password 本身也要用到服务器端支持的插件，好在 caching_sha2_password 是默认加载的，所以直接改就行：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '新密码';
这条命令之所以可行，是因为我们只是把账号的认证插件字段改成了默认插件，并不需要 mysql_native_password 参与。
修改后验证：
sql复制SELECT user, host, plugin FROM mysql.user WHERE user = 'root';
看到 plugin 变为 caching_sha2_password 就好了。后续用新密码登录正常，用旧密码登录会被拒绝，这符合预期。
注意：如果改完认证方式后，你的客户端或连接驱动不支持
caching_sha2_password，那么连接阶段可能报 2059。比如某些老版本的 PHPmysqlnd驱动、Python 的mysqlclient老版本，都可能不兼容。这种场景下，你反而需要方案一来保留mysql_native_password兼容旧客户端。
3.3 方案三：使用 --skip-grant-tables 模式绕过（应急手段，慎用）
如果你的 root 密码忘了，或者因为权限问题改不了用户表，可能会想到用 --skip-grant-tables 启动 MySQL 再修改。这个思路可以用，但要注意 1524 报错在这种模式下更容易出现。
具体做法：
- 停掉 MySQL 服务：
bash复制
systemctl stop mysqld - 以跳过权限表方式启动：
bash复制
或者直接修改配置文件临时加mysqld --skip-grant-tables --skip-networking &skip-grant-tables。 - 此时无需密码登录：
bash复制
mysql -uroot - 执行
FLUSH PRIVILEGES;，让权限表生效。 - 然后修改 root 认证方式：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '新密码';
这里有一个大坑：在 --skip-grant-tables 模式下，如果你不先执行 FLUSH PRIVILEGES; 就直接 ALTER USER，MySQL 会报错：ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement。所以顺序必须是：登录后先 FLUSH PRIVILEGES;，再改密码。我见过不少人在这个坑里卡住，一直以为是自己命令写错了。
另外提醒一下，--skip-grant-tables 模式下 MySQL 不校验权限，存在安全风险。务必加上 --skip-networking 禁止远程连接，改完密码后立刻恢复正常模式重启服务。
3.4 方案选型建议
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 只是临时改个密码，客户端较新 | 方案二 | 不额外加载旧插件，更安全 |
有旧客户端、旧驱动依赖 mysql_native_password |
方案一 | 保持兼容性，最小化改动 |
| root 密码忘记，无法正常登录 | 方案三 | 绕过权限限制，应急恢复 |
| 生产环境且业务复杂 | 先方案一，再考虑方案二 | 先在测试环境验证客户端兼容性再切换 |
优先级上，我一般建议能走方案二就不走方案一，因为 mysql_native_password 是旧认证协议，安全隐患明显。但如果你有大量旧客户端，只能先方案一稳定业务，再逐步升级客户端，最后彻底切换。
4. 被问爆的连带问题：从 1524 到 2059、2002 的避坑清单
排查 1524 的过程中，我发现它经常和另外几个错误一起出现，而且很多人会连着踩坑。这里一并讲讲。
4.1 报 2059 是客户端的问题，别在服务器端死磕
ERROR 2059 (HY000): Authentication plugin 'mysql_native_password' cannot be loaded 看起来和 1524 很像，但它通常发生在客户端。意思是：服务器要求用 mysql_native_password 认证，但客户端这边找不到对应的插件实现。
最典型的场景是：服务器上的用户是 mysql_native_password，但客户端版本太老，或者客户端库不完整。解决办法是更新客户端、升级驱动，或者干脆把服务器账号改成 caching_sha2_password。
这里有个判断技巧：155 开头的错误多数是服务器端状态问题，2059 是客户端插件问题。报 2059 时，你先用新版 MySQL 官方客户端试试连接，如果新版客户端能连上，基本就是客户端或驱动太老。
4.2 报 2002 不是认证问题，是连接通道问题
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' 在热搜词里也出现了。这不是认证相关，而是根本连不上服务器。常见原因：
- MySQL 服务没启动。
- socket 文件路径不对，客户端找
/tmp/mysql.sock，但服务端生成在/var/lib/mysql/mysql.sock。 - 权限问题，客户端无法访问 socket 文件。
解决办法：
bash复制systemctl status mysqld
如果没启动，先启动服务。如果 socket 路径不一致，登录时指定 socket：
bash复制mysql -uroot -p -S /var/lib/mysql/mysql.sock
或者在配置文件的 [client] 段加：
ini复制socket=/var/lib/mysql/mysql.sock
4.3 报 1290 是模式限制，不是密码错误
ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option 这个我在方案三里提到过。如果你用跳过权限表方式启动了服务，任何需要写权限表的操作都会被拦。解决方式就一句：先执行 FLUSH PRIVILEGES;。
4.4 报 1396 是用户不存在或 host 不匹配
ERROR 1396 (HY000): Operation ALTER USER failed for 'root'@'localhost' 也经常和 1524 混在一起出现。这个错误的意思是你要改的这个用户不存在，或者 host 部分和实际不匹配。
常见原因：
- 用户实际是
'root'@'127.0.0.1'，而不是'root'@'localhost'。 - MySQL 8.0 中 root 用户可能是多个 host 条目，你只改了其中一个，另一个还是旧插件。
- 大小写问题，比如
Root和root被当成不同用户。
排查方式：
sql复制SELECT user, host, plugin FROM mysql.user WHERE user = 'root';
如果看到多行不同 host 的 root 用户，逐个确认并修改。有些版本的 MySQL 默认会有 'root'@'localhost' 和 'root'@'127.0.0.1' 两条记录，如果你只改了 localhost，用 127.0.0.1 连接时仍可能遇到问题。
4.5 MySQL 9.0 及以后的趋势判断
Oracle 已经在 MySQL 9.0 中移除了 mysql_native_password 插件，这意味着未来 MySQL 官方发行版不会再有这个插件文件。如果你现在还在用 8.0，趁业务还没完全依赖它，尽早把客户端、驱动都升级到兼容 caching_sha2_password 的版本，能省掉后续很多麻烦。
我在自己维护的一套系统里，已经把所有应用账号都切到了 caching_sha2_password，同时在过渡期保留了 mysql_native_password 给几个旧服务。等到旧服务升级完，我再把配置文件里的 mysql_native_password=ON 删掉，保证环境干净且安全。
5. 实测之后的一些个人建议和操作细节
5.1 改完配置一定要验证，别只看命令成功就收工
无论你用的是方案一还是方案二，改完以后都建议做一套完整的验证流程：
sql复制# 查看账号当前认证插件
SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'root';
# 退出后用新密码登录
mysql -uroot -p
然后实际执行一条需要权限的查询，比如：
sql复制SHOW DATABASES;
如果登录成功且能查询，说明权限和认证都没问题。有些情况下，ALTER USER 虽然执行成功，但客户端连接时仍然报认证失败，就是因为缓存或连接池还保留了旧连接，需要断开重连。
我在测试时就遇到过一个怪现象：命令行能登录，但应用连不上。排查了半天，发现应用连接池里缓存了旧密码和旧认证信息，重连机制没有生效。所以验证时最好重启一下应用或者清掉连接池。
5.2 遇到 1524 时，别盲目执行一堆命令
我看到不少人在网上求助时贴了一长串命令，什么 UPDATE mysql.user SET plugin='mysql_native_password'、FLUSH PRIVILEGES; 之类的，把自己的库折腾得越来越乱。这里强调一下：
- 不要直接
UPDATE mysql.user SET plugin='mysql_native_password'，因为如果服务器没加载这个插件，改完以后这个账号可能根本无法登录。 - 不要同时混用
INSTALL PLUGIN和ALTER USER，先想清楚你要保留旧协议还是切换到新协议。 - 不要在生产库上随手
SET GLOBAL改全局变量，除非你确定重启后配置依然生效。
最安全的流程是：先查清楚现状，再选择一个方案执行，执行完立即验证。
5.3 写配置文件的路径和注意事项
如果你想把 mysql_native_password 设为默认加载，配置文件的位置因系统而异。常见的有：
/etc/my.cnf/etc/mysql/my.cnf/etc/mysql/mysql.conf.d/mysqld.cnf- CentOS 下有时是
/etc/my.cnf.d/下的某个文件
用 mysql --help | grep my.cnf 可以查看当前实例会读取哪些配置文件。改完以后记得重启：
bash复制systemctl restart mysqld
重启后再次确认插件状态：
sql复制SHOW PLUGINS;
查看是否包含 mysql_native_password。如果配置没生效，多半是写错了段（比如写到了 [client] 而不是 [mysqld]），或者配置项名称不兼容。
5.4 一个通用思路：版本升级前先做兼容性检查
无论你是从 MySQL 5.7 升级到 8.0，还是从 8.0 升级到 9.0，升级前都应该检查一下应用端使用的认证方式和驱动版本。我用过一个比较笨但有效的方法：在测试环境把所有应用的数据库账号列出来，逐一检查它们的认证插件：
sql复制SELECT user, host, plugin FROM mysql.user;
然后把所有应用跑一遍回归测试，重点看登录、查询、写入功能是否正常。认证插件变更往往是升级过程中最隐蔽的破坏点，它不会让 SQL 语句报错，但会让应用在连接初期就失败，而且日志信息不一定直观。
5.5 最后的最后：一个小技巧
如果你在做 ALTER USER 时经常忘记指定认证插件，可以用 MySQL 8.0 的默认行为来简化操作。直接执行：
sql复制ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';
不写 WITH 插件名，MySQL 会使用该账号当前的插件，或者使用全局默认插件。大多数情况下这就足够了，还不会触发 1524。只有当你想主动切换插件时，才需要写出 IDENTIFIED WITH 子句。
不过这条规则有个例外：如果你的全局默认认证插件被改成了 mysql_native_password，而服务器又没加载它，那即使不写 WITH 也可能报 1524。所以还是那句：动手之前先查默认插件和现有插件状态。
我在实际处理这类问题时的习惯是：先花一分钟 SHOW PLUGINS; 和查 mysql.user，把服务器状态摸清楚，再决定用哪个方案。这样看起来多了一步，但能避免很多不必要的折腾。