根本原因是MySQL 8.4官方主动移除mysql_native_password插件默认加载，属硬性变更；需先在[mysqld]段配置mysql_native_password=ON并重启启用插件，再执行ALTER USER切换用户认证方式并FLUSH PRIVILEGES生效。
MySQL 8.4 报错 “Plugin 'mysql_native_password' is not loaded” 的根本原因
不是配置写错了，也不是权限没给够，而是 MySQL 8.4 启动时压根不加载这个插件——它被官方主动移除默认加载逻辑，属于硬性变更。你执行 ALTER USER ... IDENTIFIED WITH mysql_native_password 时，服务器连插件名都认不出来，直接抛出 ERROR 1524 (HY000)。
检查方式很直接：SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'mysql_native_password'; —— 在干净安装的 8.4 实例上，这条语句大概率返回空结果。
- 这不是 bug，是 Oracle 官方从 8.0.34 开始标记
mysql_native_password为 deprecated，并在 8.4 中落地执行：默认不加载、不注册、不响应 - MySQL 9.0 将彻底删除该插件文件，8.4 是最后一个还能“手动拉回来”的 LTS 版本
-
default_authentication_plugin=mysql_native_password这类旧配置在 8.4 中已无效，甚至会导致 mysqld 启动失败
如何让 mysql_native_password 在 8.4 上真正可用
必须分两步走，缺一不可：先让插件“活过来”，再让用户“用起来”。只做一半，连接照样失败。
- 永久启用插件：在
my.cnf或my.ini的[mysqld]段添加mysql_native_password=ON（注意不是plugin_load_add，也不是auth_socket.so） - 重启
mysqld后验证：SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'mysql_native_password';必须看到ACTIVE - 再执行用户切换：
ALTER USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'pass123';（严禁对'root'@'%'直接操作） - 最后强制刷新：
FLUSH PRIVILEGES;—— 不执行这步，mysql.user表里的plugin字段不会更新
为什么改完用户还是连不上？客户端适配常被忽略
服务端插件启用 + 用户认证方式切换 + FLUSH PRIVILEGES 全做了，但 Navicat、PyMySQL、Spring Boot 还是报错，问题大概率出在客户端握手参数上。
- Java JDBC 连接串必须带
allowPublicKeyRetrieval=true，否则卡在公钥协商阶段，报Public Key Retrieval is not allowed - Python PyMySQL 需显式指定
auth_plugin='mysql_native_password'，否则默认尝试caching_sha2_password - Node.js 的
mysql库已停止维护，必须换用mysql2，且版本不低于 3.0 - Spring Boot 3.2.4 + HikariCP 5.x 默认不支持
caching_sha2_password握手，需升级到 HikariCP 7.0.2+ 并配置authenticationPlugins=com.mysql.cj.protocol.a.authentication.CachingSha2PasswordPlugin
更推荐的长期方案：迁移到 caching_sha2_password
硬切回 mysql_native_password 是临时止血，不是根治。8.4 仍支持它，但所有新客户端默认走 caching_sha2_password，且 9.0 彻底砍掉——你现在每多一个 mysql_native_password 用户，未来升级就多一分风险。
- 优先改造应用层：升级数据库驱动、调整连接参数、测试握手流程
- 批量迁移用户：
SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';，然后逐个执行ALTER USER 'u'@'h' IDENTIFIED WITH caching_sha2_password BY 'pwd'; - 确认系统表健康：
mysqlcheck --all-databases --check-upgrade和util.checkForServerUpgrade()能提前发现表结构损坏等底层问题，这类问题会导致ALTER USER直接失败，报ERROR 1805或ERROR 1449
真正麻烦的从来不是改一行配置或一条 SQL，而是客户端生态适配和系统表一致性——这两块漏掉任何一项，都会让你在凌晨三点面对连不上的生产库。
