MySQL 8.0默认认证插件改为caching_sha2_password，导致旧客户端连接失败；应优先通过ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password BY 'pwd'降级插件，并FLUSH PRIVILEGES。
MySQL 8.0 默认认证插件变了
MySQL 8.0 开始，mysql_native_password 不再是默认认证方式，新用户默认用 caching_sha2_password。老客户端（比如 MySQL 5.7 客户端、旧版 PHP mysqli 扩展、某些 Python pymysql 版本）不认识这个插件，连不上就报 Client does not support authentication protocol。
这不是“客户端太旧要升级”，而是服务端和客户端之间认证协议不匹配。解决方向有两个：改服务端适配客户端，或改客户端支持新协议——优先选前者，尤其当无法控制客户端环境时。
- 检查当前用户用的认证插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user'; - 如果返回
caching_sha2_password，且你用的是旧客户端，大概率就是它导致的 - 临时方案不是升级客户端，而是让该用户降级回
mysql_native_password
ALTER USER 切换认证插件（安全但需权限）
用有 CREATE USER 或 UPDATE 权限的账号执行，直接改用户认证方式，客户端完全无感。这是最稳的解法，比改全局配置更精准，也避免影响其他新用户。
注意不能只改 PASSWORD，必须显式指定 IDENTIFIED WITH：
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
- 执行后记得
FLUSH PRIVILEGES;（虽然多数情况下自动生效，但保险起见） - 如果用户是从
localhost连，host 要写成'your_user'@'localhost'，别漏掉单引号 - PHP 7.4+、Python PyMySQL 0.9.3+、MySQL Shell 8.0+ 原生支持
caching_sha2_password，这类情况建议保留新插件，升级客户端更合理
my.cnf 里禁用新认证插件（仅测试环境）
在 MySQL 配置文件 my.cnf 的 [mysqld] 段加一行，强制所有新用户都用老插件：
default_authentication_plugin=mysql_native_password
重启 MySQL 生效。这招省事，但不推荐上生产——等于把整个实例拉回旧协议，放弃 caching_sha2_password 带来的密码传输加密增强和性能优化。
- 已存在的用户不受此配置影响，仍保持原来的
plugin值 - 新创建的用户才会默认用
mysql_native_password - 某些云数据库（如阿里云 RDS、腾讯云 CDB）不允许修改此配置，只能走
ALTER USER方式
客户端连接时显式指定 auth_plugin（Python/Node.js 场景）
如果你能改代码，且用的是较新驱动，可以绕过服务端设置，让客户端主动声明支持的插件。比如 Python PyMySQL 1.0+：
conn = pymysql.connect(
host='xxx',
user='xxx',
password='xxx',
auth_plugin='mysql_native_password' # 显式指定
)Node.js 的 mysql2 同理，传 authPlugins 选项。但要注意：这不是万能补丁。
- 如果服务端用户本身是
caching_sha2_password，而你客户端又没装对应插件（比如没装 OpenSSL 支持），还是会失败 - Java 的
mysql-connector-java8.0+ 默认支持，但老版本（5.1.x）根本解析不了这个参数，会直接忽略 - 命令行客户端
mysql不支持运行时指定插件，只能靠服务端改或升级客户端二进制
真正卡住人的地方，往往不是不知道怎么切插件，而是查不到具体哪个用户、哪个 host 触发了错误——日志里只报错，不带用户名。所以第一反应不该是升级客户端，而是先 SELECT user, host, plugin FROM mysql.user 对着连不上的账号查一遍。
