MySQL 8.4 默认禁用 mysql_native_password 插件，导致旧用户导入后无法登录；需手动在 my.cnf 中配置 mysql_native_password=ON 启用，或迁移至 caching_sha2_password 认证。
mysql_native_password 插件在 MySQL 8.4 中默认不加载，不是“移除”，而是“禁用+废弃”——这意味着你仍能手动启用它，但不能再依赖它自动存在。升级后连不上，90% 是因为旧用户账号带着 mysql_native_password 插件信息被导入，而新实例根本没加载该插件。
为什么 mysqldump 导入后用户直接失效？
mysqldump --all-databases 会导出 mysql.user 表完整行，包括 plugin 和 authentication_string 字段。MySQL 8.0 用户若用的是 mysql_native_password，其哈希值是 SHA1(SHA1(password))；但 MySQL 8.4 启动时不加载该插件，服务端压根不认识这个认证方式，一尝试登录就报：Error 1524 (HY000): Plugin 'mysql_native_password' is not loaded。
- 不是密码错了，是服务端根本没注册这个插件
- 不是客户端问题（除非你用的是极老的 MySQL 5.6 客户端），是服务端配置缺失
-
SHOW PLUGINS;查不到mysql_native_password，说明它确实没加载
如何让 8.4 实例临时支持 mysql_native_password？
编辑 my.cnf 或 my.ini，在 [mysqld] 段落显式启用：
[mysqld] mysql_native_password=ON
然后重启 mysqld。注意：
- 必须写
mysql_native_password=ON，不能只写mysql_native_password（后者在 8.4 中无效） - 该配置仅控制插件是否加载，不影响已有用户的
plugin字段值 - 重启后执行
INSTALL PLUGIN mysql_native_password SONAME 'auth_socket.so';不需要——=ON已隐式完成加载 - 此方案适合测试验证阶段，不建议长期用于生产
如何把旧用户迁移到 caching_sha2_password？
这才是符合 MySQL 8.4 安全策略的长期做法。关键点不是改密码，而是改认证插件 + 重算哈希：
- 对单个用户：执行
ALTER USER 'u'@'h' IDENTIFIED WITH caching_sha2_password BY 'plain_password'; - 不能直接 UPDATE mysql.user 表——
authentication_string字段内容由插件内部生成，手填 SHA256 哈希会失败 - 如果用户密码是空的（
authentication_string为空字符串），ALTER USER会报错，需先用SET PASSWORD或临时设个密码再改 - 批量迁移可写脚本查出所有
mysql_native_password用户，逐条执行ALTER USER，避免一次性 TRUNCATE user 表
客户端连不上时，别只盯着服务器配置
有些老工具（如 Navicat 12.x、DBeaver 7.x、某些 Python 2 的 pymysql 版本）根本不识别 caching_sha2_password 协议。此时即使服务端插件已启用，客户端也可能报：Client does not support authentication protocol requested by server。
- 优先升级客户端驱动：pymysql ≥ 1.0.2、mysql-connector-python ≥ 8.0.23、Navicat ≥ 16.1
- 临时绕过：连接时显式指定认证方式，例如命令行加
--default-auth=mysql_native_password - Java 应用需检查 JDBC URL 是否含
allowPublicKeyRetrieval=true&useSSL=false（仅测试环境）
真正麻烦的不是插件切换本身，而是旧系统里那些没人记得怎么建的账号、嵌在 shell 脚本里的硬编码连接串、以及连文档都没更新的监控 agent——它们不会自己适配 caching_sha2_password，得一个个捞出来重置。
