不能直接ALTER USER切换到caching_sha2_password后让旧客户端连上，因为该插件依赖RSA密钥交换或SSL加密握手，而PHP 7.4 mysqli、Python 2 MySQLdb等旧客户端不支持该协议，导致报错“Plugin caching_sha2_password could not be loaded”或“Authentication requires secure connection”，本质是协议不识别而非密码错误。
不能直接 ALTER USER 切换到 caching_sha2_password 后就让旧客户端连上——新版插件需要客户端同步支持，否则连接直接失败。
为什么现有用户切 caching_sha2_password 后老应用会断连
MySQL 8.0 的 caching_sha2_password 插件依赖 RSA 密钥交换或 SSL 加密握手，而很多仍在运行的客户端（如 PHP 7.4 的 mysqli、Python 2 的 MySQLdb、某些 Docker 官方镜像里的 mysql-client）根本不实现该协议。错误现象典型为：Plugin caching_sha2_password could not be loaded 或 Authentication requires secure connection。这不是密码错，是协议不识别。
- 即使你执行了
ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'pwd';，只要客户端没升级，连接仍会失败 -
caching_sha2_password对未启用 SSL 的连接默认走 RSA 公钥交换，但旧驱动不发get_public_key请求，服务端收不到响应就中止认证 - 部分云数据库（如阿里云 RDS）对 RSA 公钥路径有严格限制，本地调试通不代表上线通
平滑切换必须分“服务端适配”和“客户端升级”两步走
核心原则：先让新插件在服务端就位且不影响旧连接，再逐个推动客户端升级，最后清理冗余配置。跳过任一环节都可能引发静默故障。
- 第一步：用
CREATE USER新建一个同名但带版本后缀的账号（如'app_v2'@'10.20.%'），并显式指定插件：CREATE USER 'app_v2'@'10.20.%' IDENTIFIED WITH caching_sha2_password BY 'pwd'; - 第二步：用
SHOW GRANTS FOR 'app'@'10.20.%';提取权限，再手动执行GRANT ... TO 'app_v2'@'10.20.%';—— 注意不要漏WITH GRANT OPTION和EXECUTE权限 - 第三步：只把已确认升级了驱动的新服务（比如 Java 应用用了 mysql-connector-java 8.0.28+）指向
app_v2，其他服务继续走旧账号 - 第四步：监控
performance_schema.threads表里PROCESSLIST_USER字段，确认无残留旧连接后再停用app账号
切完 caching_sha2_password 后必须检查三个隐性依赖项
插件切换只是表层动作，实际生效还卡在三个常被忽略的配置上：
- SSL 配置：若连接字符串里没加
?useSSL=true&requireSSL=true，且服务端require_secure_transport=ON，则caching_sha2_password会强制拒绝非加密连接 - 公钥路径：服务端需存在有效 RSA 公钥文件，且
caching_sha2_password_auto_generate_rsa_keys=ON或手动指定了sha256_password_private_key_path和sha256_password_public_key_path -
sql_mode差异：某些旧应用依赖NO_AUTO_CREATE_USER等已废弃模式，切插件时若同时升级 MySQL 小版本，可能触发隐式报错
真正难的不是执行那条 ALTER USER，而是确认所有调用方是否已准备好接受新协议——尤其那些没写在 Git 里的 shell 脚本、定时任务、运维工具链，它们最容易在切换后突然报错。
