那天下午我正给一个刚从 5.7 升上来的测试实例补账号SQL 刚敲完回车终端直接甩了我一脸mysql CREATE USER app_user10.10.0.% IDENTIFIED WITH mysql_native_password BY Abc_123456; ERROR 1524 (HY000): Plugin mysql_native_password is not loaded第一反应是插件没装赶紧去SHOW PLUGINS里翻结果发现mysql_native_password就在那里列着但状态是DISABLED。再仔细一想这不是环境坏了是插件在 MySQL 新版本里被默认下了岗。后来我又陆续在几个客户环境里见过同一条 ERROR 1524触发方式大同小异处理思路却要分情况。这篇就把这条报错的来龙去脉、排查方法和三条不同的出路一次讲清楚。1. 触发场景什么情况下会跟这条 ERROR 1524 撞上1.1 场景一建号/改号时手动指定旧插件最直接的触发方式就是执行CREATE USER或ALTER USER时显式写了IDENTIFIED WITH mysql_native_password。像下面这两条语句在 MySQL 8.4 及以后版本的默认配置下基本必报 1524CREATE USER demo% IDENTIFIED WITH mysql_native_password BY Demo_123456; ALTER USER demo% IDENTIFIED WITH mysql_native_password BY New_123456;原因很直观MySQL 在执行这两条语句时需要把账号的认证方式注册成mysql_native_password但它要先确认这个插件是真实可用、处于加载状态的。既然插件被默认禁用服务器就会直接拒绝执行而不是先把账号建好再让你以后想办法。很多从 MySQL 5.7 时代走过来的 DBA 都有这个惯性动作以前IDENTIFIED WITH mysql_native_password属于为了兼容老客户端才特意写的加固配置现在反而成了触发报错的开关。1.2 场景二配置文件里残留的全局限定写法另一种常见情况是旧模板里残留了这样的配置[mysqld] default_authentication_pluginmysql_native_password这个参数在 MySQL 5.7 里是官方推荐的默认认证插件指定方式到了 MySQL 8.0 里已经慢慢被边缘化8.4 直接不认这个变量。如果你拿着老配置启动新版本实例运气好是启动失败然后日志里给出unknown variable之类的提示运气差一点就是服务起来了但一建号就撞 1524。还有一部分人的配置是从网上东拼西凑来的把default_authentication_plugin和mysql_native_passwordON混在一起写。前者会让启动过程变得不稳定后者才是 MySQL 8.4 里真正用来控制这个插件的开关。配置文件里凡是涉及认证插件的地方都需要单独过一遍不能因为是老模板就想当然地保留。1.3 场景三老库升级后账号元数据仍指向旧插件这个场景最隐蔽也最容易让人误判。假设你有一个 MySQL 5.7 或 8.0 老库里面有一批账号的plugin字段本来就是mysql_native_password。升到 MySQL 8.4 之后mysql.user表里这些账号还在密码哈希也还在但服务器已经不再主动加载对应的认证插件。此时应用去连接通常不会直接报 1524而是报类似Authentication plugin mysql_native_password cannot be loaded的错误。问题容易出在修复阶段。有人想让这些老账号恢复可用手一滑写了ALTER USER old_app% IDENTIFIED WITH mysql_native_password BY Whatever_123;这时候服务器又不知道该怎么处理这个插件于是 1524 再次出现。实际上这个场景下 1524 更像是二次暴露——根本问题不是语句写法而是整批账号的认证方式已经过时需要整体迁移。2. 根因拆解mysql_native_password 的命运和 1524 的真正含义2.1 三轮版本迭代里的插件地位变化把mysql_native_password的地位变化按版本拉一条时间线事情就清楚多了版本默认认证插件mysql_native_password 状态MySQL 5.5 / 5.6 / 5.7mysql_native_password默认启用几乎所有客户端都在用MySQL 8.0caching_sha2_password仍然内置且默认启用兼容老账号MySQL 8.4caching_sha2_password默认编译但状态为 DISABLED需显式开启MySQL 9.xcaching_sha2_password不再提供无法通过开关找回MySQL 8.0 切换默认认证插件的时候官方还留了一条后路所有老库升级上来之后已有的mysql_native_password账号照样能连新账号默认用caching_sha2_password两头兼顾。但到了 8.4官方把这条后路默认关闭了插件还在服务器程序里但默认不加载所以任何显式引用它的语句都会撞上 1524。9.x 更绝直接把插件从服务器里移掉想靠配置开关找回来都不可能。2.2 1524 在说什么服务器拿不到开门的钥匙理解 ERROR 1524 不能只把它当成插件不存在。实际上 MySQL 的报错信息写得很清楚Plugin xxx is not loaded。意思是某条语句或某个账号元数据里引用了一个认证插件但服务器当前没有加载这个插件。这和Access denied有本质区别。Access denied是插件在工作密码验证没通过1524 是服务器连验证密码这件事都没法开始因为它手里没有对应的认证模块。打个比方门锁上写着必须用 A 钥匙打开但看门人手里根本没有 A 钥匙的模板你即使掏出一把长相完全正确的 A 钥匙他也没法帮你比对。这也就解释了为什么很多老账号在升级后连接失败时报的往往不是 1524而是cannot be loaded或者干脆握手失败——因为真正连接阶段还需要这个插件参与服务器加载不到就直接拒绝了。2.3 两条 SQL 快速确认插件状态遇到 1524先别急着改配置用下面两条 SQL 确认一下现场SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_TYPE FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME mysql_native_password;在这条 SQL 的结果里你会看到三种典型情况ACTIVE插件正常加载。如果此时还报 1524多半是权限、语法或者版本兼容问题需要重新审视执行环境。DISABLED插件还在服务器程序里但默认关闭。这就是 MySQL 8.4 的典型状态也是多数 1524 报错的原因。空结果插件连编译都没进服务器通常出现在 MySQL 9.x。此时不要幻想靠开关找回老老实实走账号迁移。再配合看一眼全库账号的认证插件分布SELECT user, host, plugin FROM mysql.user ORDER BY plugin, user;这两条 SQL 一跑完问题的性质基本就能定下来是配置缺了开关还是账号元数据整体停留在旧时代。3. 三条出路怎么选启旧插件、迁新认证、升驱动别拍脑袋3.1 方案A重新启用 mysql_native_password只适合 8.4如果你的实例是 MySQL 8.4且只是想在过渡期快速恢复兼容性可以重新打开旧插件。修改配置文件[mysqld] mysql_native_passwordON然后重启 MySQL 服务。重启后执行SHOW VARIABLES LIKE mysql_native_password;看到ON再去查INFORMATION_SCHEMA.PLUGINS插件状态会从DISABLED变成ACTIVE。这时候再执行之前报 1524 的CREATE USER就能正常通过了。但我不建议把这个动作当成一劳永逸的解决方案。原因有两个第一mysql_native_password的认证机制相对老旧继续让新账号使用它等于把安全水位拉回 5.7 时代第二MySQL 9.x 已经把它彻底移除就算你现在开了未来升级到 9.x 仍要面对同样的迁移问题无非是时间早晚。这个方案适合我马上要接业务先跑起来再说的紧急止血场景。3.2 方案B把账号迁移到 caching_sha2_password长期来看正路是把账号的认证方式统一切到caching_sha2_password。操作本身很简单ALTER USER app_user% IDENTIFIED WITH caching_sha2_password BY New_Stron_g123;这里有一个必须提前说清的细节mysql_native_password用的是SHA1(SHA1(password))这样一套哈希caching_sha2_password用的是 SHA256 家族的哈希两者不是同一个密码重新命名就能互相转换的。也就是说迁移账号必须配合一次密码重置不可能保留原来的密码哈希原地切换。实际操作时你要先跟应用负责人确认新的连接密码再执行ALTER USER最后让应用侧更新连接串。安全性上caching_sha2_password默认启用。它是基于 SHA256 的挑战-响应认证并且加入了一个缓存机制同一账号在短时间内重复认证时可以直接走缓存性能损耗很小。非 SSL 连接首次认证时可能需要额外进行 RSA 公钥交换如果你的客户端支持--get-server-public-key或连接串里配置了ssl-modeREQUIRED这一环也能顺利渡过。3.3 方案C升级客户端连接库让生态跟上很多时候报 1524 的实例是被老客户端逼着改回去的。一个项目如果还停在 MySQL 5.7 时期的连接驱动大概率不认识caching_sha2_password那么即便你把账号迁到新认证应用也会报The server requested authentication method unknown to the client这个时候反而觉得还不如开旧插件。更健康的思路是把客户端驱动也升上来。比如 Java 项目把 MySQL Connector/J 升到 8.0.33 以上PHP 项目确认使用的是新版 mysqlndPython 项目把 PyMySQL 升到 1.0 以上。驱动一旦支持新认证意味着你既能安全地用caching_sha2_password又不用时刻惦记兼容性旧账。3.4 选型对照表临时与长期之间怎么权衡碰到具体环境可以按下面这张表对号入座判断维度启用 mysql_native_password迁移到 caching_sha2_password升级客户端驱动恢复速度最快重启即可中等要协调改密偏慢要发布变更是否适合 8.4适合临时可用适合长期方案适合任何版本是否适合 9.x不支持必须必须安全水平停留在 5.7 时代8.0 之后的标准取决于驱动版本对业务影响需要重启实例需要改应用密码需要应用发版适用场景半夜救火、过渡收敛正规项目收尾老代码维护期一句话总结重启一次能解决的事就用方案A先救如果这个库还要活一两年方案B是主线如果应用代码根本不受控那方案C再难也得做。4. 实测记录我在 MySQL 8.4 上复现并解决 1524 的完整过程4.1 复现报错确认插件状态为 DISABLED我在一台测试机上装了 MySQL 8.4 官方版本正常启动后直接执行建号语句CREATE USER legacy_user% IDENTIFIED WITH mysql_native_password BY Legacy_123456;输出和文章开头一样ERROR 1524 (HY000): Plugin mysql_native_password is not loaded接着查插件状态SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME mysql_native_password;结果--------------------------------------- | PLUGIN_NAME | PLUGIN_STATUS | --------------------------------------- | mysql_native_password | DISABLED | ---------------------------------------这基本实锤了不是语句写错不是权限问题是插件被默认禁用。此时mysql.user表里没有任何使用mysql_native_password的账号全表都是caching_sha2_password。4.2 调整配置并重启实例我编辑了 MySQL 配置文件在[mysqld]段落下加了一行[mysqld] mysql_native_passwordON重启服务systemctl restart mysqld重启后验证变量和插件状态SHOW VARIABLES LIKE mysql_native_password;结果-------------------------------- | Variable_name | Value | -------------------------------- | mysql_native_password | ON | --------------------------------再看插件状态已经变成ACTIVE。这里补充一点如果你遇到的是 MySQL 9.x执行同样的配置后服务很可能直接起不来日志里会报未知变量。所以动手前先确认版本别在 9.x 上浪费半小时。4.3 重建账号并验证登录行为确认插件激活后我重新执行了刚才失败的建号语句CREATE USER legacy_user% IDENTIFIED WITH mysql_native_password BY Legacy_123456;这次没有报错。验证一下用户表SELECT user, host, plugin FROM mysql.user WHERE user legacy_user;结果------------------------------------------ | user | host | plugin | ------------------------------------------ | legacy_user | % | mysql_native_password | ------------------------------------------然后用命令行客户端尝试登录mysql -ulegacy_user -pLegacy_123456 -h127.0.0.1连接成功说明整条链路已经通了。4.4 顺手验证关掉旧插件后老账号会怎样本来到这里问题就算解决了但我想验证一下如果不开这个开关老账号到底会怎么死于是又把配置里的mysql_native_passwordON去掉重启服务再用同一个账号去连。结果在意料之中连接阶段直接失败报错信息类似Authentication plugin mysql_native_password cannot be loaded。这个验证过程挺有意义它让你直观理解 1524 和连接失败的关联插件禁用状态下涉及该插件的管理语句报 1524涉及该插件的连接请求直接握手失败。两者其实是同一个根因。5. 升级前就该做好的四件小事账号盘点、驱动检查、参数确认与回滚预案5.1 盘点全库账号的认证方式分布升级之前先在老实例上跑这么一条汇总 SQLSELECT plugin, COUNT(*) AS cnt FROM mysql.user GROUP BY plugin;如果结果里mysql_native_password占据了很大比例说明升级到 8.4 会有一大批账号需要处理维护窗口要留足。更完整的做法是直接用 MySQL Shell 的升级检查器util.checkForServerUpgrade它会自动扫描老实例的路由、权限、认证等兼容性问题比肉眼翻mysql.user靠谱得多。5.2 检查应用侧驱动版本与连接参数这一步经常被忽略。很多团队只在服务器上折腾忘了看应用连接层。确认完账号分布后至少检查这几项应用连接数据库用的驱动包版本号尤其是 Java 的 Connector/J 和 PHP 的 mysqlnd。连接串里是否设置了ssl-mode以及是否需要get-server-public-key。是否有备份工具、定时任务用到了老版mysqldump或老客户端这些工具往往也会被认证方式变化卡住。驱动版本一旦确认方案A和方案B的优先级就清楚了驱动太老可能需要方案A过渡驱动较新直接方案B。5.3 确认这台 MySQL 能不能改服务器参数同样是 MySQL 8.4在不同部署形态下处理方式完全不同。自己装在本机的实例改my.cnf重启就能生效Docker 容器需要把配置文件挂载进容器注意官方镜像的配置读取顺序云托管数据库则要看控制台的参数组是否暴露了mysql_native_password这个变量很多托管实例不开放这个参数那你能走的就只有方案B和方案C。动手之前先把部署形态和参数可改范围确认清楚否则改完配置才发现实例在别人手里就尴尬了。5.4 备份 mysql.user 并准备回滚方案无论走哪条路升级前都要把账号表备份一份。最稳妥的方式是完整备份 mysql 库mysqldump --single-transaction --routines --triggers mysql mysql_backup_$(date %F).sql这条命令会把mysql.user、mysql.db、存储过程等相关元数据全部导出。万一升级后发现某账号连不上或者批量改认证方式时写错了范围还能把旧账号元数据捞回来。这里提醒一句恢复账号表之前先确认新旧版本兼容别把 5.7 的mysql.user整表恢复到 8.4那会引起另一场事故。一点收尾的个人体会处理这类认证插件问题我的习惯永远是先确认版本和账号分布再决定动不动机器。见过太多人在 8.4 上把default_authentication_plugin写进配置然后把服务搞到起不来的案例。如果你也只是想在过渡期快速恢复业务mysql_native_passwordON确实是最快的开关但要记得在运维记录里写清楚临时方案限期内迁移。如果已经上了 MySQL 9.x那就别再惦记旧插件了把账号迁移到caching_sha2_password、把客户端驱动升级到位才是唯一走得通的路。最后留一个排查小技巧遇到 1524 时顺手看一眼SHOW VARIABLES LIKE default_authentication_plugin的输出。很多连接问题不是出在账号本身而是新旧配置里的默认认证方式不一致这一句 SQL 往往能帮你少走不少弯路。