MySQL 8.0默认的认证插件是caching_sha2_password，这不是什么推荐选项，而是直接取代了mysql_native_password。为什么这么决绝？因为老家伙在安全上已经彻底站不住了。如果你还在用mysql_native_password，现在真得认真想想——它用的是SHA1(SHA1(password))存储，连个盐值都不加。这意味着什么？同一密码会产生完全相同的哈希值，在mysql.user表里扫一眼，哪些账号共用密码一目了然，GPU跑几分钟就能把常见密码字典扫完，几乎等于裸奔。更致命的是，握手阶段的challenge-response数据可以被截获重放，即使在内网或跳板机场景，如果没强制SSL，漏洞清晰可见。

它解决的是真实被利用的漏洞，不是理论风险

而新插件caching_sha2_password则强行引入了三个硬核防护：每个用户生成独立20字节随机salt，写入authentication_string的前缀；密码哈希不再是简单SHA1重复，而是SHA256(salt + password)，再迭代5000轮SHA256；非SSL连接下，必须通过服务器RSA公钥加密传输中间值，这需要客户端显式允许allowPublicKeyRetrieval=true。这简直是给密码加了铜墙铁壁，老漏洞一个都别想进来。

它的“caching”只加速验证，不降低安全水平

名字里的“caching”不是吹的——它指的是服务端内存缓存已验证的凭据对，仅用于短时间内的重复连接复用。首次连接耗时跟sha256_password一样，都需要做那5000轮SHA256运算；但缓存命中时，耗时能下降60%到80%，TTL默认300秒，重启就失效。重要的是，缓存里不存明文，不存原始哈希，只存一次校验通过后的会话标识。安全水平不但没降，反而因为严格的校验流程，得到进一步加固。必须警惕的是，它只管用户身份的合法性，并不干预SQL执行的危险性。哪怕你用caching_sha2_password登录成功，拼接字符串的查询照样会被注入——这跟插件毫无关系。

兼容性问题不是插件的缺陷，而是客户端没走对协议路径

很多人遇到Public Key Retrieval is not allowed或Unknown system variable 'caching_sha2_password'的报错，就觉得插件有问题。其实问题出在客户端身上：JDBC驱动版本低于8.0.9，不支持RSA密钥交换流程；Na vicat ≤ 12.1还沿用旧版libmysqlclient，无法处理公钥协商；PHP的mysqli和PDO_MySQL扩展至今（2026年）仍未原生支持这个插件；Docker容器里client lib版本滞后的情况也很常见，比如Ubuntu 20.04自带的MySQL client低于8.0.28。真正容易被忽略的点是：这个插件和SQL注入完全无关，它只管你是不是合法用户，不管你执行的SQL是否危险。这是必须提前说明的事实。