应使用caching_sha2_password——它采用sha256+动态salt、支持ssl直传或rsa加密传输、服务端缓存优化性能，而mysql_native_password因sha1脆弱、无salt、已弃用，安全性与合规性均不足。
因为它是 MySQL 8.0 官方推荐的、更安全且性能不妥协的认证方式，不是“建议用”，而是“应该用”——除非你明确接受兼容性让步和安全降级。
为什么 mysql_native_password 已经不够用了
mysql_native_password 使用 SHA1 基础的 scramble 机制，存在几个硬伤：
- SHA1 算法已被证实可被碰撞攻击，哈希值容易被逆向或撞库
- 不强制加密传输，明文密码（或弱哈希）可能在非 SSL 链路上暴露
- 无 salt 或 salt 固定，抗彩虹表能力极弱
- MySQL 8.0.34 起已标记为
deprecated，未来版本会移除
caching_sha2_password 的真实优势不止是“更安全”
它不是单纯换了个哈希算法，而是一整套升级的认证模型：
-
caching_sha2_password默认使用 SHA256 + 动态 salt，每次登录 salt 都不同，防重放、防暴力破解 - 支持两种安全路径：SSL/TLS 加密通道下直接传密码（信道本身保安全），或非 SSL 下通过 RSA 公钥加密密码再传输
- 服务端缓存用户公钥和认证状态，重复登录跳过部分计算，实测比
mysql_native_password更快 - 不依赖 OpenSSL，自带 RSA 实现，部署更轻量
别被“连不上”误导，问题不在插件本身，而在连接方式
报错 Authentication plugin 'caching_sha2_password' cannot be loaded 或 Authentication requires secure connection，本质是客户端没走对路：
- 老版 Navicat / PHP 7.3 及以下 / 某些 JDBC 驱动未启用 SSL 也未配置
--server-public-key-path，就会失败 - 连接字符串漏了
SslMode=Required（.NET）或?ssl-mode=REQUIRED（Python/Go） - MySQL 服务端没开 SSL（
have_ssl为DISABLED），又没配 RSA 密钥，等于只留了一扇锁着的门
真正该花时间的，不是回退到 mysql_native_password，而是确认你的客户端是否能走 SSL，或者能否安全加载服务器公钥——这两条路都通，caching_sha2_password 就不会拦你。忽略这点直接改插件，等于把防盗门换成纱窗，还怪小偷太勤快。
