mysql 8.0默认使用caching_sha2_password而非mysql_native_password，因其强制盐值、5000轮sha256迭代及rsa加密传输，彻底解决后者无盐哈希、明文协商和易被重放等真实安全漏洞。
caching_sha2_password 不是“推荐用”，而是 MySQL 8.0 的默认认证插件——它取代 mysql_native_password 是因为后者在安全上已不可接受。
它解决的是真实被利用的漏洞，不是理论风险
mysql_native_password 存储密码的方式是 SHA1(SHA1(password))，没有盐值：
- 相同密码 → 完全相同的哈希值，攻击者扫一眼
mysql.user表就能发现哪些账号共用密码 - 没有迭代轮数，GPU 几分钟就能跑完常见密码字典
- 握手阶段 challenge-response 数据可被截获重放，尤其在未强制 SSL 的内网或跳板机场景
而 caching_sha2_password 强制引入三个硬性防护：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 每个用户生成独立 20 字节随机
salt，写入authentication_string字段前缀 - 密码哈希 =
SHA256(salt + password)，再迭代 5000 轮SHA256 - 非 SSL 连接下，必须通过服务器 RSA 公钥加密传输中间值（需客户端显式允许
allowPublicKeyRetrieval=true）
它的“caching”只加速验证，不降低安全水位
名字里的 “caching” 指服务端内存缓存已成功认证的凭据对，仅用于短时间内的重复连接复用：
- 首次连接耗时 ≈
sha256_password（都要做 5000 轮 SHA256） - 缓存命中时耗时下降 60%~80%，TTL 默认 300 秒，重启即失效
- 缓存不存明文、不存原始哈希，只存一次校验通过后的会话标识
兼容性问题不是插件的缺陷，而是客户端没走对协议路径
报错 Public Key Retrieval is not allowed 或 Unknown system variable 'caching_sha2_password'，通常是因为：
- JDBC 驱动版本
- Navicat ≤ 12.1 使用旧版
libmysqlclient，无法处理公钥协商 - PHP 的
mysqli和PDO_MySQL扩展至今（2026 年）仍未原生支持该插件 - Docker 容器内 client lib 版本滞后（如 Ubuntu 20.04 自带的 MySQL client
真正容易被忽略的点是：这个插件和 SQL 注入完全无关。它只管“你是不是合法用户”，不管“你执行的 SQL 是否危险”。哪怕你用 caching_sha2_password 登录成功，拼接字符串的查询照样被注入。
