为什么MySQL 8.0删除了query_cache并在配置中如何替代它？-mysql教程-PHP中文网

mysql 8.0 彻底删除 query_cache_type 等所有查询缓存变量，配置即报错启动失败；必须手动清除 my.cnf 中所有 query_cache_ 开头的行，并改用 innodb 缓冲池优化、应用层缓存等替代方案。

为什么mysql 8.0删除了query_cache并在配置中如何替代它？

MySQL 8.0 里根本不存在 query_cache_type 这个变量——不是“关了”，是源码里删干净了；配置文件里留着它，MySQL 直接启动失败。

my.cnf 里还留着 `query_cache_*` 就起不来服务

从 MySQL 8.0.3 起，所有 query_cache_type、query_cache_size、query_cache_limit 等变量全被物理删除。mysqld 启动时解析配置，遇到不认识的变量就报错退出，典型错误是：Unknown system variable 'query_cache_type' 或 Unknown variable 'query_cache_size'。

必须手动删除 my.cnf（或 my.ini）中所有以 query_cache_ 开头的行，包括注释掉的（如 # query_cache_type = 1）也要删，某些解析器会误判
Percona Server 8.x、MariaDB 10.6+ 同样不识别，别指望兼容
云数据库（RDS）、Docker 镜像若复用旧参数组或配置模板，同样卡在这一步，得逐项检查并清理
验证方式：启动前执行 mysqld --validate-config，比靠日志翻找更直接

`SELECT SQL_CACHE` 在 MySQL 8.0 中直接报语法错误

这不是提示被忽略，而是 SQL 解析器压根不再支持该关键字。执行类似语句会立刻失败：

SELECT SQL_CACHE * FROM users WHERE id = 1;

报错：ERROR 1286 (42000): Unknown table engine 'QUERY CACHE'。连语法树构建阶段都过不去，没有 fallback 行为。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

SQL_NO_CACHE 同样无效，但不会报错（只是被静默丢弃）
试图用 init_connect + 自定义函数拦截 SQL 并模拟缓存？不可靠：无法感知隐式 DDL（如 ALTER TABLE ... RENAME COLUMN），也无法处理 MVCC 快照一致性
社区没有安全、可靠的 Query Cache 插件——官方不提供，第三方实现绕不过事务可见性与主从延迟问题

真正该调的不是查询缓存，而是 `innodb_buffer_pool_size`

InnoDB Buffer Pool 是现代 MySQL 最关键的缓存层，它缓存的是数据页而非 SQL 结果，无全局锁、无表级失效风暴、命中后直接内存读，且与写操作天然协同。

中低端服务器建议设为物理内存的 50%–75%，例如 2GB 总内存可设 innodb_buffer_pool_size = 1G（注意单位！写成 1024M 或 1G，不能只写 1024）
验证是否生效：SHOW STATUS LIKE 'Innodb_buffer_pool_read%'，计算 Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads，比值 > 99% 才算健康
避免和 Query Cache 当年一样的陷阱：不要迷信“缓存结果”，要优先保证热数据页常驻内存——索引设计、覆盖索引、慢查优化比任何结果缓存都实在

应用层缓存比 SQL 级缓存更可控

Query Cache 失败的本质，是在 SQL 解析层强行做结果级缓存，却扛不住数据一致性压力。替代方案的关键不是“换一个缓存”，而是换位置、换粒度、换控制权。

高频只读小数据（如配置项、状态码）：用 apcu_store()/apcu_fetch()（PHP）或 Redis 的 SETEX config:app:features 3600 {...}
维度表（城市、分类）：加 WHERE updated_at 条件，缓存 1 小时，更新时主动 <code>DEL key
聚合统计（日订单数）：改用定时任务预计算，结果存 cache:daily_order_count，避免实时 COUNT 压垮 DB
绝不缓 SELECT * FROM users WHERE id = ? 这类通用查询——除非你明确拼出 user:123 这样的 key，并在 UPDATE 后主动失效

最易被忽略的一点：即使你在旧版 MySQL 上配好了 query_cache_size，只要 SQL 里带 NOW()、用户变量、子查询或临时表，结果照样不进缓存——而这些在 ORM 和现代业务逻辑里太常见了。与其花时间调参，不如把精力放在 Buffer Pool 容量、索引有效性、以及哪条 SQL 真正值得缓到应用层。