必须分阶段迁移并验证客户端兼容性与服务端配置，盲目执行alter user会导致旧客户端断连；需检查plugin状态、ssl/rsa配置、客户端版本及require_secure_transport等参数。
不能直接在现有用户上执行 ALTER USER ... IDENTIFIED WITH caching_sha2_password 就认为切换完成——旧客户端会立刻断连，错误不是“密码错”，而是协议不识别。
确认当前插件状态和客户端兼容性
先查清楚你面对的是什么问题，而不是盲目切插件：
- 执行
SELECT User, Host, plugin FROM mysql.user;，重点看目标用户（比如'app'@'192.168.%'）的plugin字段是否已是caching_sha2_password；如果不是，说明还没被影响，别急着改 - 检查你的客户端版本：PHP 7.4 的
mysqli、Python 2 的MySQLdb、Java 用mysql-connector-java 都不支持该插件的 RSA 密钥交换流程 - 如果连接串里没带
?useSSL=true&requireSSL=true，且服务端require_secure_transport=ON，那即使客户端支持，也会被拒绝
服务端启用caching_sha2_password的三个必要条件
插件本身已内置，但要真正生效，必须同时满足：
-
ssl_ca、ssl_cert、ssl_key至少有一组有效配置（哪怕只是自签名证书），否则非 SSL 连接无法走 RSA 公钥交换 - 若用 RSA 方式（即未启用 SSL），需确保
sha256_password_public_key_path或caching_sha2_password_public_key_path指向有效的public_key.pem，且权限为 644、属主为mysql - 服务端不能禁用
caching_sha2_password插件：检查SHOW PLUGINS;中该插件状态是否为ACTIVE；若为DISABLED，需在my.cnf中显式启用：plugin_load_add = caching_sha2_password.so
分阶段迁移：新建账号 + 权限同步 + 渐进切换
这是唯一能避免业务中断的路径，跳过任一环节都可能引发静默故障：
- 用新账号隔离风险：执行
CREATE USER 'app_v2'@'192.168.%' IDENTIFIED WITH caching_sha2_password BY 'real_pwd'; - 复制权限：运行
SHOW GRANTS FOR 'app'@'192.168.%';，把输出中的GRANT语句逐条执行到'app_v2'@'192.168.%'，特别注意WITH GRANT OPTION和EXECUTE权限不能漏 - 只让已验证的新服务指向
app_v2，旧服务继续走原账号；通过performance_schema.threads监控PROCESSLIST_USER字段，确认无残留连接后再停用旧账号
主从/Group Replication场景下的特殊要求
这类场景对 caching_sha2_password 更敏感，容易卡在握手阶段：
- 主从复制用户必须配置 RSA 密钥对，且主库和从库的
public_key.pem要一致；云数据库（如阿里云 RDS）通常不开放密钥路径配置，此时只能降级插件 - Group Replication 的恢复用户（recovery user）若用此插件，在
group_replication_ssl_mode=DISABLED时，必须手动部署 RSA 密钥，并确保所有节点可读取private_key.pem - 错误日志中出现
Authentication requires secure connection且发生在 IO 线程或 group replication 启动阶段，基本可锁定为 RSA 或 SSL 配置缺失
最常被忽略的是：插件切换后，require_secure_transport 和 caching_sha2_password_auto_generate_rsa_keys 这两个变量的状态会直接影响连接能否建立——它们不是“开了就自动好”，而是需要和客户端行为严格对齐。调试时优先查这两个值，比反复重试 ALTER USER 有效得多。
