MySQL 8.0.3起已物理删除所有query_cache_*系统变量，若JDBC驱动或连接池尝试读取query_cache_size等参数，将直接抛出Unknown system variable错误；根本解决路径是清理配置、升级驱动、修正连接串并禁用相关缓存逻辑。
mysql 8.0.3起已物理删除所有`query_cache_*`系统变量，若jdbc驱动或连接池尝试读取`query_cache_size`等参数，将直接抛出`unknown system variable`错误；根本解决路径是清理配置、升级驱动、修正连接串并禁用相关缓存逻辑。
当你在使用 HikariCP 连接 MySQL 8.0+ 时遇到如下典型错误：
Failed to create/setup connection: Unknown system variable 'query_cache_size'
这并非配置遗漏或权限问题，而是MySQL 8.0.3 及以上版本已彻底移除查询缓存（Query Cache）子系统——包括 query_cache_type、query_cache_size、query_cache_limit 等全部变量均被物理删除，服务启动时若配置文件中存在相关项会直接报错退出；而更隐蔽的是：某些旧版 JDBC 驱动（即使为 8.x）或中间件组件（如部分 ORM 封装层、监控代理、连接池抽象层）仍会在连接建立初期主动探测这些已废弃变量，从而触发该异常。
✅ 根本原因与三步修复法
1️⃣ 彻底清除服务端残留配置（必须）
检查 MySQL 配置文件（my.cnf 或 my.ini），删除所有以 query_cache_ 开头的行，包括：
- 显式配置：query_cache_type = 1
- 注释行：# query_cache_size = 1048576（某些解析器会误识别！）
- 空格/缩进变体：query_cache_limit = 2M
⚠️ 注意：SET GLOBAL query_cache_type = 0 在 8.0+ 中已无效，执行即报错，不可用于“兼容性关闭”。
2️⃣ 验证并强制使用新版驱动与类名
尽管你已引入 mysql-connector-java:8.0.33，但需确保：
- 驱动类名严格为 com.mysql.cj.jdbc.Driver（非 com.mysql.jdbc.Driver）；
- 检查项目 classpath 是否存在多个 MySQL 驱动 JAR 冲突（如同时存在 5.1.x 和 8.x），可通过 mvn dependency:tree | grep mysql 排查；
- Spring Boot 用户请确认未显式 exclude 默认驱动后又手动降级引入旧版。
3️⃣ 修正 JDBC URL —— 补全 8.0 强制参数
MySQL 8.0+ 默认启用 caching_sha2_password 认证插件，并强制 SSL 与严格时区校验。缺失任一关键参数均可能导致连接握手阶段失败，并间接触发对已删变量的探测行为。推荐标准连接串（URL 编码安全）：
jdbc.master.url=jdbc:mysql://localhost:6033/test?\ useSSL=false&\ allowPublicKeyRetrieval=true&\ serverTimezone=Asia/Shanghai&\ characterEncoding=utf8mb4&\ cachePrepStmts=true&\ prepStmtCacheSize=250&\ prepStmtCacheSqlLimit=2048
✅ 关键参数说明： | 参数 | 必需性 | 说明 | |------|--------|------| | useSSL=false | ⚠️ 强制（开发环境） | 8.0 默认要求 SSL，无证书时必须显式关闭；生产环境应配证书并设为 true | | allowPublicKeyRetrieval=true | ⚠️ 强制（8.0.4+） | 否则 RSA 密钥交换失败，报 Public Key Retrieval is not allowed | | serverTimezone=... | ⚠️ 强制 | 否则报 The server time zone value 'XXX' is unrecognized；推荐 Asia/Shanghai 或 UTC | | characterEncoding=utf8mb4 | ✅ 推荐 | 替代过时的 utf8（仅支持 3 字节），完整支持 emoji 与四字节 Unicode | | cachePrepStmts=true&... | ✅ 必配（MyBatis/动态 SQL 场景） | 新驱动默认禁用预编译缓存，缺失将导致 IN 列表过长、分页等语句执行异常 |
? 补充调优建议（防关联故障）
- 连接池空闲管理：HikariCP 的 idleTimeout 应设为 MySQL wait_timeout 的 70%～80%（如 DB 设为 300 秒，则填 240000 毫秒），避免连接被服务端静默 kill；
- 健康检查：弃用 connectionTestQuery=SELECT 1（已废弃），改用 validationTimeout=3000 + keepaliveTime=300000 主动保活；
- 应用级缓存替代：若业务曾依赖 Query Cache 的自动 SELECT 缓存，请迁移到 Redis 或 Caffeine 等应用级缓存方案，MySQL 8.0 中 SELECT SQL_NO_CACHE 已完全无效，须一并清理。
✅ 验证清单（部署前必检）
- [ ] my.cnf 中无任何 query_cache_ 字符串
- [ ] pom.xml / build.gradle 仅含 mysql:mysql-connector-java:8.0.33+
- [ ] 全项目搜索 com.mysql.jdbc.Driver 并替换为 com.mysql.cj.jdbc.Driver
- [ ] JDBC URL 包含 useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=
- [ ] 日志中不再出现 query_cache_size、Public Key Retrieval、server time zone 相关错误
完成上述步骤后重启应用，HikariCP 初始化将跳过已废弃变量探测流程，连接池可稳定建立。MySQL 8.0 的性能提升正源于此——移除全局查询缓存锁竞争后，高并发写入与复杂查询吞吐量显著增强；而真正的缓存策略，应交由更灵活、可观测、可分级的应用层实现。
