MySQL 8.0 彻底物理删除查询缓存模块，非仅禁用或限于MyISAM；所有query_cache_*变量、逻辑、锁机制均被移除，配置即报错，必须清空配置文件中所有相关行（含注释），否则启动失败。
query_cache 在 MySQL 8.0 中根本不存在，不是“针对 MyISAM”才移除的——它被一并从整个系统中物理删除，MyISAM 和 InnoDB 都不支持。
MySQL 8.0 启动报 Unknown variable 'query_cache_type' 怎么办
这不是配置写错了，是变量名本身已被编译器剔除。MySQL 8.0.3 起，所有 query<em>cache</em>* 相关逻辑（包括解析、内存分配、锁机制）全被删光。
- 必须手动删掉
my.cnf（或mysqld-auto.cnf）里所有以query<em>cache</em>开头的行，注释掉也不行（某些版本仍会解析失败） - Docker 或云数据库（如 RDS）若用了自定义参数组，同样要清理残留项
- 检查是否干净：执行
SELECT VARIABLE_NAME, VARIABLE_SOURCE FROM performance_schema.variables_info WHERE VARIABLE_NAME LIKE 'query_cache%';，结果必须为空
为什么不是“只对 MyISAM 移除”，而是彻底砍掉
query_cache 的设计缺陷与存储引擎无关，但和 MyISAM 共存时问题更隐蔽：
- 它的失效粒度是表级（table-level），任何
INSERT/UPDATE/DELETE都清空整张表所有缓存条目，而 MyISAM 表无事务、无 MVCC，更新更频繁，缓存刚建好就被清空 -
LOCK_query_cache是全局单点互斥锁，高并发下几十个 SELECT 线程排队等锁，CPU 花在上下文切换而非查数据 - SQL 字节级匹配（大小写、空格、注释、客户端字符集）导致 ORM 和预处理语句基本无法命中，MyISAM 常用于只读报表场景，看似适合，实则因动态生成 SQL 而几乎零命中
升级后性能下降，别怪 query_cache 没了
QPS 下降 90% 的真实原因和缓存缺失无关：
-
PERSIST机制覆盖了你的my.cnf：执行过SET PERSIST sort_buffer_size = 64K会写入mysqld-auto.cnf，优先级更高 - 统计信息过期：
INNODB_TABLESTATS.last_update停在升级前，优化器误判行数，走错索引 -
optimizer_switch默认值变更：比如mrr=off（5.7 是on），导致范围查询变慢
真正该调的是 innodb_buffer_pool_size（设为物理内存 50%–75%）和应用层缓存（如 Redis 存用户配置），而不是花时间找一个已经不存在的开关。query_cache 的幽灵还在不少模板里残留，删掉它，系统反而更轻、更稳、更容易诊断。
