根本原因是caching_sha2_password在客户端不支持RSA密钥交换且未启用TLS时，会阻塞于安全协商流程，导致连接超时或长时间无响应；常见于旧版Navicat、未更新的mysqlclient、mysqli及部分JDBC驱动。
为什么caching_sha2_password连接会变慢
根本原因不是插件本身慢，而是它在特定条件下触发了额外安全协商流程：当客户端不支持 RSA 密钥交换、又没启用 TLS 时，caching_sha2_password 会卡在等待加密通道建立或密钥传输阶段，表现为连接超时或长时间无响应。这不是网络延迟，是协议握手被阻塞。
常见触发场景包括：用旧版 Navicat（12 及更早）、未更新的 Python mysqlclient、PHP mysqli 扩展、某些 JDBC 驱动（如 mysql-connector-java
- SSL 关闭 + 客户端无 RSA 支持 → 握手失败前会重试多次，感知为“慢”
- 服务端配置了
require_secure_transport=ON，但客户端走的是普通 TCP → 直接拒绝，不报错只卡住 - 客户端尝试加载
caching_sha2_password.so插件失败（如 macOS 上路径不对）→ 报错后 fallback 延迟明显
ALTER USER 切换插件时必须带密码
执行 ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'pwd' 是最直接的解法，但漏掉 BY 'pwd' 会导致密码被清空——这不是警告，是真实发生的行为。很多用户改完发现连不上，就是因为只写了 IDENTIFIED WITH mysql_native_password，没补密码。
- 检查当前插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'root'; - 远程访问需同时改两个 host：
'root'@'localhost'和'root'@'%' - 改完必须执行
FLUSH PRIVILEGES;，否则内存缓存未更新，新设置不生效
default_authentication_plugin 配置只影响新用户
在 /etc/my.cnf 的 [mysqld] 段下加 default_authentication_plugin=mysql_native_password，重启 MySQL 后，所有后续 CREATE USER 创建的账号才默认用这个插件。已有账号（包括初始化的 root）完全不受影响，仍保持 caching_sha2_password。
特别注意 Docker 场景：即使配置了该参数，若启动容器时用了 MYSQL_ROOT_PASSWORD 环境变量，root 用户仍会被初始化为 caching_sha2_password，必须进容器手动 ALTER USER。
- 验证是否生效：
SHOW VARIABLES LIKE 'default_authentication_plugin'; - 配置文件中已有该行，就改值，不要重复写
[mysqld]段 - Ubuntu/Debian 下配置文件常在
/etc/mysql/mysql.conf.d/mysqld.cnf，别改错位置
客户端侧绕过服务端插件协商
不改服务端配置时，可在客户端强制指定认证方式。比如命令行连接：mysql -u root -p --default-auth=mysql_native_password -h 192.168.1.100。这个参数会让客户端跳过插件协商，直连 mysql_native_password 流程。
对程序代码也有效：Python 的 pymysql 可传 auth_plugin='mysql_native_password' 参数；JDBC URL 加 &serverTimezone=UTC&allowPublicKeyRetrieval=true&useSSL=false（仅限测试环境）。
-
--default-auth是客户端行为，服务端无需配合 - Navicat 中可在连接属性 → 高级 → “使用身份验证插件”里选
mysql_native_password - 此法适合临时调试，长期应统一服务端插件策略，避免混用导致权限管理混乱
真正难处理的不是切换插件本身，而是确认哪些账号已被修改、哪些还卡在旧插件上——尤其在多环境部署时，很容易漏掉某个 'user'@'10.%' 这类通配 host 的账号。建议每次操作后用 SELECT user, host, plugin FROM mysql.user; 全量扫一遍，别只查 root。
