必须手动删除my.cnf中所有以query_cache_开头的行，包括注释；MySQL 8.0.3起该变量已从源码物理移除，残留配置将导致启动失败。
MySQL 8.0 启动报 Unknown system variable 'query_cache_type' 怎么办
这不是配置写错了，是变量本身已被源码删除。MySQL 8.0.3 起，query_cache_type、query_cache_size、query_cache_limit 等所有相关变量全部从内核中物理移除——配置文件里哪怕只留一行 query_cache_type = 0，mysqld 解析时就会报错并退出。
必须手动删掉 my.cnf（或 my.ini）中所有以 query_cache_ 开头的行，包括注释掉的也得清干净。Docker 镜像、RDS 参数组、Percona Server 8.x 同样不识别，不存在“兼容模式”或“设为 OFF 就能绕过”的可能。
为什么 MySQL 5.7 的 Waiting for query cache lock 在 8.0 里消失了
因为底层全局锁 LOCK_query_cache 被一并删了。在 5.7 中，这个锁会卡住所有访问缓存路径的操作：查缓存、写缓存、清缓存都得排队抢它。
- 哪怕只是检查
SELECT * FROM users WHERE id = 123是否命中，也要等锁 - 一次
UPDATE users SET name='x' WHERE id=123，不仅清空整张表所有缓存，清空过程本身还要持锁 - 高并发下，几十个 SELECT 线程堆在锁上，
%systemCPU 异常升高，实际执行时间反而变短
8.0 移除后，这部分锁竞争和上下文切换开销彻底消失，资源直接让给 innodb_buffer_pool_size 和更细粒度的页级缓存逻辑。
JDBC 连接失败提示 query_cache_size 错误，其实是驱动没升级
旧版 JDBC 驱动（如 com.mysql.jdbc.Driver）在握手阶段会主动探测 query_cache_size 等变量，而 8.0 已不响应——结果不是连接超时，而是直接报 Unknown system variable 'query_cache_size'。
关键修复点：
- 驱动类名必须换成
com.mysql.cj.jdbc.Driver - 确认 Maven 实际加载的是
mysql-connector-java-8.0.33+，而非残留的 5.x 版本 - Spring Boot 项目要检查是否显式排除了
spring-boot-starter-jdbc，导致降级使用旧驱动 - 连接 URL 需补全
?serverTimezone=UTC&allowPublicKeyRetrieval=true&useSSL=false等 8.0 强制参数，否则握手失败日志可能被误判为缓存变量问题
别再纠结“怎么配 query_cache”，该盯紧 innodb_buffer_pool_size
Query Cache 被删不是放弃缓存，而是把资源腾给真正可控、可扩展的机制：innodb_buffer_pool_size 是现在唯一需要调优的核心缓存开关。
它缓存的是数据页，支持 MVCC、LRU-K 淘汰、无全局锁；而 Query Cache 缓存的是结果集，字节级匹配、表级失效、预处理语句绕过——现代 ORM 场景下基本零命中。
真正影响性能的，从来不是“有没有查询缓存”，而是：innodb_buffer_pool_size 是否设到物理内存的 70%～80%，慢查询有没有漏建索引，连接池是不是在反复创建销毁。
