MySQL 8.0 彻底移除查询缓存，配置 query_cache_type 会导致启动失败；需删除配置文件中所有 query_cache_ 相关项并重启 mysqld，监控和 SQL 中的缓存相关逻辑须全面替换为 InnoDB 缓冲池、索引优化及应用层缓存等真实有效策略。
MySQL 8.0 中 query_cache_type 已不存在，不是“失效”，而是代码层彻底删除——配置它会直接启动失败。
查配置文件里还有没有 query_cache_ 相关项
升级后 mysqld 启动报错 Unknown system variable 'query_cache_type'，说明配置文件（/etc/my.cnf 或 /etc/my.cnf.d/*.cnf）中仍残留了 query_cache_type、query_cache_size 等行。这些参数在 8.0.3 及之后版本已被移除，无法识别。
- 运行
mysqld --print-defaults确认哪些配置文件被加载 - 用
grep -r "query_cache_" /etc/my.cnf*扫描所有配置位置 - 找到后直接删除整行，不要注释——注释仍可能干扰某些解析逻辑
- 删完必须重启
mysqld，仅 reload 不生效
别再依赖“缓存命中率”指标
5.7 中看 SHOW STATUS LIKE 'Qcache_hits' 有值，不代表缓存真在起作用；8.0 中这条命令返回空，不是 bug，是功能归零。很多旧监控脚本或运维习惯还在抓 Qcache_ 状态，结果全是 0，容易误判为“缓存没配好”。
-
SHOW VARIABLES LIKE 'query_cache%'在 8.0 中结果为空，这是正常现象 - 应用层若曾靠
SELECT SQL_CACHE ...控制缓存，这些提示词现在被完全忽略，应一并从 SQL 中清除 - 监控系统里所有基于
Qcache_的告警和图表，需下线或替换为Innodb_buffer_pool_read_requests/Innodb_buffer_pool_reads等真实 I/O 指标
优化方向不是加内存，而是换策略
把 innodb_buffer_pool_size 从 128MB 加到 4GB，对高频重复查询的帮助远大于幻想“恢复查询缓存”。但前提是：这个缓冲池得真正被用起来——靠索引，而不是靠缓存 SQL 文本。
- 用
EXPLAIN FORMAT=JSON检查慢查询是否走了覆盖索引；例如SELECT status, city FROM users WHERE status = 'active'，建索引(status, city)后，全走内存，无需回表 - 高频只读小表（如字典、配置），用应用层 Redis 缓存，键建议用业务语义生成（如
config:site_settings），而非 SQL MD5——后者难 debug、易冲突 - 聚合类查询（如日活、销售额汇总）改用预计算表 + 定时任务更新，避免每次请求都扫大表
- 确认连接池开启了
cachePrepStmts=true（Java）、prepared_statement_cache_size（Python mysql-connector）等客户端预编译缓存，减少 parse 开销
最常被忽略的一点：8.0 默认开启 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup，但若升级前没启用 dump，或 dump 文件路径权限不对，重启后缓冲池就是冷的——这时加内存也没用，得先让热数据载入。执行 SET GLOBAL innodb_buffer_pool_load_now = ON 并观察 SHOW STATUS LIKE 'Innodb_buffer_pool_load_status' 是否完成，比调 query_cache_size 实在得多。
