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