MySQL 8.4/9.0报错1524：认证插件未加载的修复指南

1. 先搞明白ERROR 1524到底在说什么1.1 认证插件MySQL登录时的“身份核验方式”很多人在第一次见到ERROR 1524 (HY000): Plugin mysql_native_password is not loaded的时候第一反应是去改密码、重置权限折腾一圈下来发现一点用都没有。这个错跟密码本身没关系它卡在登录链路更靠前的一环MySQL 不认识你想用的认证插件。MySQL 的用户账号不只是user和password这么简单。每个账号背后都有一个plugin字段它决定了服务器用什么算法来校验你的密码。你可以把它理解成手机解锁的方式有的用 PIN 码有的用指纹有的用面部识别。MySQL 也一样mysql_native_password是一种算法caching_sha2_password是另一种算法。执行一条 SQL 的时候服务器一看你的账号要求用 A 算法但当前进程里根本没有加载这个算法插件它就甩出 ERROR 1524。所以这个错误的关键词不是“密码错误”而是“插件没加载”。服务端没有启用或内置该插件只要 SQL 里出现IDENTIFIED WITH mysql_native_password无论给什么密码都会立刻被拒绝。1.2 MySQL 8.0以后认证机制为什么大变mysql_native_password是 MySQL 5.7 及更早版本里的默认认证插件用了很多年稳定可靠。但它有一个硬伤密码校验过程基于 SHA1 的挑战-响应机制安全强度在今天的视角下已经不够看了。密码的哈希值一旦泄露离线爆破成本很低。所以 MySQL 8.0 做了两件事第一把默认认证插件换成caching_sha2_password基于 SHA256安全性提升一大截第二把mysql_native_password标记为废弃逐渐收紧它的存在感。到了 8.4mysql_native_password默认变成禁用状态到了 9.0干脆从安装包里直接移除。这个变化对老项目非常不友好。很多从 5.7 迁移上来的业务客户端、连接池、ORM 都还是按老插件写的升级到 8.0 以后连接直接报错于是大家第一反应就是想改回老插件。但改的前提是服务端得先把这个插件加载起来。而 1524 恰恰就是“你想用但服务端没有”的尴尬现场。1.3 ERROR 1524出现的典型现场我实际处理过的报错现场最常见的是下面这几种ALTER USER app_user% IDENTIFIED WITH mysql_native_password BY App2025;CREATE USER legacy_user% IDENTIFIED WITH mysql_native_password BY legacy_pwd;这两条语句在 MySQL 8.4 或 9.0 上执行大概率会直接返回ERROR 1524 (HY000): Plugin mysql_native_password is not loaded还有一类场景是配置文件里设了全局默认认证方式。比如从老服务器迁移配置过来带了这样一行default_authentication_plugin mysql_native_password到了 8.4这个参数已经废弃改用authentication_policy。如果 8.4 里设置了authentication_policy mysql_native_password而插件又是禁用状态那么不仅执行 SQL 会报错甚至启动时日志里也会出现一堆警告新建用户全卡在认证这步。搞清楚成因接下来就是排查和修复的事。2. 三步定位先查状态再选方案2.1 第一步确认服务端加载了哪些认证插件遇到任何和认证插件有关的错误第一件事不是改配置而是先看清楚当前服务端到底有哪些插件可用。用 root 账号本机登录 MySQL优先走 socket 方式执行SHOW PLUGINS;输出会有一大串重点看名字带password的那几行。在 MySQL 8.0 里你会看到类似这样的状态mysql_native_password | ACTIVE | AUTHENTICATION | auth_native_password.so | GPL caching_sha2_password | ACTIVE | AUTHENTICATION | auth_socket.so | GPL在 8.4 默认配置下mysql_native_password这一行很可能是mysql_native_password | DISABLED | AUTHENTICATION | NULL | GPL注意这个DISABLED它对应的就是“插件存在但没加载”。如果是在 9.0 或者某些精简编译的 8.0 镜像里干脆一整行都查不到。也可以只看类型为认证的插件SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_LIBRARY FROM information_schema.PLUGINS WHERE PLUGIN_TYPE AUTHENTICATION;这一步能非常清晰地判断你需要的插件是“禁用”还是“不存在”。“禁用”还能打开“不存在”就得想别的办法。2.2 第二步看清当前账号的认证方式接下来看现有用户分别用的什么插件SELECT user, host, plugin FROM mysql.user;正常输出的样子---------------------------------------------------- | user | host | plugin | ---------------------------------------------------- | root | localhost | auth_socket | | app_user | % | caching_sha2_password | | legacy_user | % | mysql_native_password | ----------------------------------------------------这里有个很容易忽略的细节mysql.user里记录的是账号当前的认证方式不代表服务端已经加载了对应插件。换句话说账号表里写着mysql_native_password但服务端插件是 DISABLED那么该账号登录大概率会出问题所有试图把它改回老插件的新操作也都会被 1524 拦下。再看全局默认值SHOW VARIABLES LIKE default_authentication_plugin; SHOW VARIABLES LIKE authentication_policy;8.0 看第一个8.4 看第二个。这决定了你新建用户时不指定插件会默认用哪种。2.3 第三步根据版本选择修复路径插件状态和 MySQL 版本组合起来基本只有下面三种情况版本插件状态修复方向MySQL 8.0未加载但编译了插件INSTALL PLUGIN加载或者配置开启MySQL 8.4 LTS默认 DISABLED在my.cnf里设置mysql_native_password ONMySQL 9.0已移除无法恢复必须改用caching_sha2_password确认版本的方式很简单SELECT VERSION();很多朋友会忽略这步直接复制网上的ALTER USER语句去执行结果在 9.0 上被 1524 反复折磨还以为是语法问题。3. 实操记录从报错到恢复的完整过程3.1 场景复现迁移脚本里的老语句我前阵子帮一个团队处理过一模一样的报错。他们的环境是 MySQL 8.4.2数据从老库迁过来账号是通过迁移脚本重建的。脚本里有一条CREATE USER billing% IDENTIFIED WITH mysql_native_password BY Billing2025; GRANT SELECT, INSERT, UPDATE ON billing.* TO billing%;执行到第一句就直接报ERROR 1524 (HY000): Plugin mysql_native_password is not loaded当时现场第一反应是“密码策略问题”试了各种复杂密码全被同一个 1524 顶回来。后来我用SHOW PLUGINS一看mysql_native_password状态是DISABLED瞬间定位到原因。如果你也遇到完全相同的情况可以直接照着下面操作。3.2 在MySQL 8.4中启用mysql_native_password既然 8.4 里插件默认禁用那就手动打开它。编辑 MySQL 配置文件常见路径是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf在[mysqld]段下加一行[mysqld] mysql_native_password ON注意8.4 里已经不推荐使用default_authentication_plugin mysql_native_password这种写法了该参数已被废弃优先用mysql_native_password ON单独控制这个插件的加载状态。保存后重启服务systemctl restart mysqld重启后再查插件状态SHOW PLUGINS;看到mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL说明已经加载成功。注意LIBRARY是NULL因为 8.4 里它是内置插件不需要动态库文件。然后重新执行迁移脚本里的建用户语句或者临时改现有账号ALTER USER billing% IDENTIFIED WITH mysql_native_password BY Billing2025;再查询确认SELECT user, host, plugin FROM mysql.user WHERE user billing;输出mysql_native_password收工。如果你不想让所有新用户默认都走老插件这个配置只负责“让插件可用”不影响默认策略。想控制新建用户的默认认证方式8.4 要用authentication_policy[mysqld] authentication_policy caching_sha2_password这样只有显式写了IDENTIFIED WITH mysql_native_password的账号才会用老插件。3.3 在MySQL 9.0和8.0中分别怎么处理9.0 是完全不同的情况。前面说过9.0 里mysql_native_password已经从安装包里移除了。你执行SHOW PLUGINS整张表里都找不到这个插件配置文件里写mysql_native_password ON也会被忽略甚至可能导致服务启动失败。9.0 里唯一的正经出路是改用caching_sha2_passwordALTER USER billing% IDENTIFIED WITH caching_sha2_password BY Billing2025;这条语句在任何 8.0 以上版本都有效也是我最推荐的方向。客户端连接时不再依赖老插件安全性也更好。如果你的业务客户端比较老连接时会报 1251 错误那是客户端侧的兼容性问题解决办法是升级客户端库或调整连接参数而不是强行给服务端开老插件。8.0 的情况比较特殊。通常 8.0 的官方包默认就带mysql_native_password但偶尔会遇到两种情况一是某些定制化发行版、云厂商 RDS 或精简镜像把插件摘掉了二是安全基线直接把插件禁用。这时候执行建用户语句一样会报 1524。处理方式比 8.4 多一招可以动态加载插件不需要重启服务INSTALL PLUGIN mysql_native_password SONAME auth_native_password.so;执行成功后插件状态变成 ACTIVE后续ALTER USER、CREATE USER就都正常了。不过这个动作是运行时生效的重启后是否保留取决于插件是否被写入了mysql.plugin表。如果重启后又恢复原样就还是老老实实在my.cnf里加上mysql_native_password ON再重启。3.4 验证环节不管是哪种方案最后都要用真实连接验证一遍而不是只查表状态。推荐这样做先确认服务端监听正常mysql -h127.0.0.1 -P3306 -ubilling -pBilling2025这里特意用 TCP 而不是 socket因为很多问题只在 TCP 连接时暴露。socket 连接经常默认走auth_socket或 root 身份掩盖了认证插件的真实情况。如果连接成功再用应用侧的真实客户端测试一把。比如 Java 的 JDBCString url jdbc:mysql://127.0.0.1:3306/billing ?useSSLfalse allowPublicKeyRetrievaltrue;allowPublicKeyRetrieval这个参数对caching_sha2_password很重要。在非 SSL 连接下客户端需要向服务端请求 RSA 公钥完成密码交换默认是禁用的不加这个参数有时候会莫名其妙连不上。这是很多程序升级到 8.0 之后连接失败的第二大原因仅次于 1251。如果验证时发现旧脚本还使用了PASSWORD()函数比如UPDATE mysql.user SET authentication_string PASSWORD(Billing2025) WHERE user billing;你会看到另一个经典错误ERROR 1300 (HY000): Invalid use of type given原因很直接PASSWORD()函数在 MySQL 8.0 里已经被移除了语法解析器还认识它但执行器直接拒绝。官方要求你改用ALTER USER ... IDENTIFIED BY ...这种语法。这个坑和 1524 经常出现在同一个迁移项目里因为老脚本里用PASSWORD()给mysql.user表写过哈希值的习惯实在太普遍了。4. 更容易一起踩的衍生错误与避坑清单4.1 这些错误经常和1524成对出现处理认证问题的时候很少只有 1524 一个错误。我在实际项目里见到最多的组合是下面这些错误信息出现场景处理思路ERROR 1524 (HY000)使用mysql_native_password但插件未加载启用插件或改用 caching_sha2_passwordERROR 1251 (08004)老客户端不支持 caching_sha2_password升级客户端库或临时把账号改回老认证ERROR 1300 (HY000)脚本里用了已被移除的 PASSWORD() 函数改成 ALTER USER 或直接给明文字符串ERROR 1396 (HY000)ALTER USER 目标用户不存在或已存在检查用户名和 host 写没写对ERROR 1698 (28000)root 账号走 auth_socket 插件限制用 sudo mysql 登录或改 root 插件这几个错误的核心都围绕“认证插件”这一个主题。1524 是服务端插件缺失1251 是客户端能力不足1300 是旧语法残留1698 是插件策略限制。排错的时候把它们当成一个整体看能少走很多弯路。4.2 老客户端兼容性怎么判断既然 mysql_native_password 已经边缘化迟早要面对 caching_sha2_password 的客户端兼容问题。判断自己的客户端是否支持可以从这几个角度快速过一遍如果是 JDBC 应用MySQL Connector/J 8.0 及以上版本支持 caching_sha2_password低于 5.1 的老驱动连不上时优先升级驱动。连接串加上allowPublicKeyRetrievaltrue基本能解决公钥交换问题。如果是 PHP 项目PHP 7.4 以上版本的 mysqlnd 支持 caching_sha2_password。我踩过最典型的坑是 PHP 7.2 老 PDO 模块数据库连接在升级后直接 1251升级 PHP 版本后一切正常。如果是 PythonPyMySQL 1.0 以上、mysql-connector-python 8.0 以上都能正常支持。早期版本需要手动把账号改成老认证现在基本不用了。如果是图形化客户端老版本 Navicat 连不上 8.0 也是老话题了。Navicat 16 以上支持 caching_sha2_password旧版建议升级。如果你确认客户端暂时没法升级实在需要临时降压可以把特定账号改成老插件。这里给一个相对安全的做法ALTER USER billing% IDENTIFIED WITH mysql_native_password BY Billing2025;但这应当是短期方案不是长期策略。安全团队审计的时候看到还在用 mysql_native_password 的账号大概率会要求限期整改。4.3 生产环境操作前必看的注意事项被 1524 教育过几次之后我总结了一套自己的操作习惯写在这里供参考。第一任何修改认证插件的操作都先备份mysql.user表。可以用 mysqldump 单独导出也可以直接建表备份CREATE TABLE mysql.user_bak_20250101 AS SELECT * FROM mysql.user;需要恢复的时候用反向 UPDATE 或者直接替换表记录。这个习惯救过我一次当时改 root 账号的插件没改对导致 root 无法登录最后是把旧记录更新回去才恢复的。第二不要在连接高峰直接 ALTER 正在被业务使用的账号。一个账号的认证方式切换后已有的长连接不会立刻断但新连接必须用新认证方式。为了避免应用旧连接池里的连接重建时连环报错我会先把代码侧的连接参数准备好再快速执行 ALTER把时间窗口压到几秒内。第三有条件的话先在一台测试实例上完整走一遍流程。特别是 8.4 和 9.0两者对 mysql_native_password 的态度完全不一样一个能开、一个彻底没门。少走弯路的最好办法就是先看版本再决定方案。第四修改完配置文件重启后看一眼错误日志tail -f /var/log/mysql/error.log有时候my.cnf里同时写了废弃参数和新增参数参数之间互相打架MySQL 会默默忽略其中一个只在日志里留一行 warning。这种隐藏问题不会立刻暴露但会在未来某个新建用户的时候突然冒出来。我个人在处理完 1524 这类错误后还会顺手做一件事把项目里所有创建用户、修改密码的 SQL 脚本统一排查一遍凡是出现IDENTIFIED WITH mysql_native_password的都改成caching_sha2_password凡是出现PASSWORD()函数的都改成ALTER USER ... IDENTIFIED BY。一次迁移把后顾之忧断干净比等到上线前再被 1524 和 1300 来回折腾要省心得多。