MySQL 8.0.3+ 彻底删除查询缓存模块，配置中残留 query_cache_type 等变量将导致 mysqld 启动失败并报错“Unknown system variable”，必须整行删除配置项、重启服务，且 SHOW VARIABLES LIKE 'query_cache%' 返回空结果才属正常。
不是“失效”，是MySQL 8.0直接删掉了查询缓存——配置里留着query_cache_type，mysqld根本启动不了。
升级后服务起不来：配置残留触发启动失败
MySQL 8.0.3+ 彻底移除了所有 query_cache_* 系统变量，连定义都没有。只要配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）里还存在 query_cache_type、query_cache_size 这类行，mysqld 就会报错退出：
Unknown system variable 'query_cache_type'
这不是“缓存没生效”，而是进程压根没起来。QPS 归零，不是性能下降，是服务中断。
- 用
grep -r "query_cache" /etc/my.cnf*扫描全部配置位置，找到就整行删除（别注释！某些解析器会误读注释里的关键字） - 改完必须执行
systemctl restart mysqld；reload不生效 - 确认清除干净：
SHOW VARIABLES LIKE 'query_cache%'应返回空结果集
误以为“缓存没了所以变慢”：实际瓶颈根本不在这里
很多团队在 5.7 时代依赖查询缓存“掩盖”低效 SQL，比如没索引的 SELECT * FROM orders WHERE status = 1。升级到 8.0 后缓存一消失，这些语句立刻暴露真实 I/O 开销，QPS 断崖下跌——但问题从来不在“缓存有没有”，而在“SQL 走不走索引”。
-
EXPLAIN是唯一可信指标：重点看type（至少range或ref）、key（是否命中索引）、rows（预估扫描行数） - 典型拖垮 QPS 的写法：
LIMIT 100000, 20分页、IN (SELECT ...)子查询、JOIN字段无索引 -
SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests'和Innodb_buffer_pool_reads的比值，比任何Qcache_*都更能反映真实缓存效率
监控和应用层还在找“Qcache_hits”，结果全是 0
SHOW STATUS LIKE 'Qcache_%' 全是 0，不是 bug，是正常行为。MySQL 8.0 已无该状态变量。但如果你的监控系统仍基于 Qcache_hits 告警，或应用代码里还写着 SELECT SQL_CACHE ...，就会产生严重误判：
-
SQL_CACHE提示词被完全忽略，不报错也不生效，但监控图表持续告警“缓存命中率 0%”，引发无效排查 - 所有基于
Qcache_lowmem_prunes或Qcache_inserts的看板、告警必须下线，替换为Innodb_buffer_pool_read_requests、Handler_read_next等真实 I/O 指标 - 应用层若用 ORM 自动生成带
SQL_CACHE的语句（如旧版 Laravel、Django），需批量清理或升级驱动
真正卡住 QPS 的，从来不是“缓存开关”，而是数据访问路径是否高效。删掉 query_cache_type 只是撕掉一层遮羞布；后面要盯的，是每一条 EXPLAIN 输出里的 rows 值，和每一次磁盘 read 是否真的必要。
