MySQL 8.0 并未禁用 mysql_native_password 插件，而是默认不再启用它；该插件仍存在、可加载、能用，但因依赖不安全的无 salt SHA1 哈希而被降权，需显式用 ALTER USER ... IDENTIFIED WITH mysql_native_password 切换，且必须带 BY 指定密码。
MySQL 8.0 并没有“禁用”mysql_native_password插件，而是默认不再为新用户启用它——该插件仍存在、可加载、能用，但被主动降权。真正的问题是：服务端没开、客户端连不上、用户没切，三者叠加导致连接失败。
为什么 mysql_native_password 被默认弃用
因为它依赖 SHA1 哈希（SHA1(SHA1(password))），无 salt、无迭代、输出固定，极易被彩虹表和 GPU 暴力破解。输入 'root' 总是得到 *81F5E21E35407D884A6CD4A731AEBFB6AF209E1B，等于变相泄露密码一致性。NIST 已明确建议 2026 年起全面停用 SHA1。
- 两个用户设相同密码 → authentication_string 完全一致 → 攻击者可定向爆破
- challenge-response 协议不强制加密通道 → 中间人可截获协商数据
- 无法抵抗现代哈希算力，也不支持密钥派生（如 PBKDF2、bcrypt）
ALTER USER ... IDENTIFIED BY 为什么不能切换认证方式
这条命令在 MySQL 8.0+ 中默认沿用用户当前的 plugin 字段值，不会自动降级到 mysql_native_password。执行后查 SELECT user, host, plugin FROM mysql.user，结果仍是 caching_sha2_password。
- 必须显式写明插件：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456'; - 只改密码哈希（如用
SET PASSWORD）完全无效 - 漏写
BY 'xxx'会导致密码被清空，锁死自己
为什么 my.cnf 里加 default_authentication_plugin 没生效
配置项位置或版本兼容性出错是最常见原因。
-
default_authentication_plugin必须放在[mysqld]段下，写在[client]或[mysql]段无效 - MySQL 8.4+ 已弃用该配置项，应改用
authentication_policy=mysql_native_password - 改完必须完整重启 MySQL（
systemctl restart mysqld），FLUSH PRIVILEGES或 reload 不起作用 - 云数据库（如阿里云 RDS）通常禁止修改
my.cnf，这条路直接走不通
为什么客户端报 “plugin not loaded” 却连不上
错误信息里的 “not loaded” 是误导性表述——实际是客户端根本不认识这个插件名，不是服务端没加载。
- Navicat ≤ 12.1、PyMySQL mysql-connector-java caching_sha2_password 的 RSA 密钥交换流程
- Navicat 会缓存连接配置，改完服务端后不关掉重开、不删旧连接重建，它可能还在用旧握手参数重试
- host 写
localhost却没同步改'root'@'localhost'，或者密码含@、/被 URL 解析吃掉——这些细节比插件切换本身更常导致失败
最常被忽略的一点：MySQL 用户记录是按 user@host 全匹配的。'root'@'localhost'、'root'@'127.0.0.1'、'root'@'%' 是三个完全独立的账户，插件和密码都得分别处理。
