caching_sha2_password 与防 SQL 注入无关，它仅强化连接认证阶段的安全性：防止密码明文传输、抵御哈希爆破、支持 RSA 加密交换；而 SQL 注入发生在查询执行层，须靠预编译语句、参数化查询及输入校验来防御。
MySQL 8.0 默认启用 caching_sha2_password 不是为了防 SQL 注入，而是为了提升认证环节的安全性；它对 SQL 注入毫无防护作用，该插件和查询执行、参数绑定、输入校验完全无关。
为什么改用 caching_sha2_password 跟防注入没关系
SQL 注入发生在应用层拼接 SQL 字符串时，防御靠的是预编译语句（如 PreparedStatement）、参数化查询、输入过滤或 ORM 的自动转义。而 caching_sha2_password 只管「你是不是合法用户」——它在 TCP 连接建立后、任何 SQL 执行前就完成了，连数据库权限检查都还没开始。
常见误解是：「用了新认证插件，SQL 就安全了」。错。一个用 caching_sha2_password 认证成功的用户，如果应用代码里还写 "SELECT * FROM users WHERE name = '" + userInput + "'"，照样被注入。
- 它解决的是密码传输明文、哈希易破解、中间人窃取凭据等问题
- 它不校验、不解析、不拦截任何一条
SELECT或INSERT语句 - 它甚至不知道你接下来要执行什么 SQL
caching_sha2_password 实际防护的三类风险
这个插件针对的是连接建立阶段的薄弱点，不是查询执行阶段：
- 密码哈希存储更难爆破：使用加盐 + 5000 轮 SHA256，
authentication_string字段长度达 70 字节，相同密码也生成不同哈希 - 非 SSL 连接下避免明文传密：通过服务器 RSA 公钥加密密码再传输（前提是客户端允许公钥获取）
- 重复连接更快验证：成功登录后缓存哈希对，后续连接跳过完整计算流程，但缓存只存在内存中，重启即失效
注意：caching_sha2_password 要求连接必须满足以下任一条件，否则直接拒绝认证：
- 启用了 SSL/TLS（推荐，设
SslMode=Required） - 未启用 SSL，但客户端显式允许公钥获取（如 JDBC 加
allowPublicKeyRetrieval=true） - 未启用 SSL 且不允许公钥获取 → 报错
Public Key Retrieval is not allowed
真正防注入该做什么（而不是动认证插件）
如果你的目标是防注入，caching_sha2_password 不是你该调的配置项。重点在应用侧和数据库权限设计：
- 所有用户连接字符串强制加
SslMode=Required（NetCore/Java/Python 都支持），杜绝凭据被嗅探 - 业务账号一律禁用
INFORMATION_SCHEMA查询：REVOKE SELECT ON TABLE INFORMATION_SCHEMA.* FROM 'appuser'@'%' - 不用
GRANT ALL ON *.*，精确到GRANT SELECT (id,name) ON mydb.users TO 'reader'@'%' - 敏感表不暴露字段名：用视图封装，比如
CREATE VIEW v_orders AS SELECT order_id, status FROM orders - 绝不信任客户端输入：后端必须做白名单校验、长度限制、正则过滤，不能只靠前端 JS
最后提醒一句：很多团队把 ALTER USER ... IDENTIFIED WITH mysql_native_password 当成“快速解法”，这等于把门锁换成纸糊的——解决了连不上问题，却把整个认证防线主动拆掉。真正的复杂点从来不在插件开关，而在如何让安全机制不干扰开发节奏，又不妥协底线。
