17370845950

MySQL 8.0 彻底移除 query_cache 是因其实现缺陷导致高并发写场景下缓存频繁失效，成为 OLTP 性能瓶颈；替代方案需分层设计，包括应用层缓存、ProxySQL、InnoDB 缓冲池优化等。

MySQL 8.0 彻底移除了 query_cache，不是禁用，是代码级删除——你再怎么设 query_cache_type=1 或调大 query_cache_size 都会报错 Unknown system variable。

为什么不能简单“换一个缓存开关”

Query Cache 的设计缺陷在高并发写场景下非常致命：只要表有任意一行被修改，所有命中该表的缓存结果全部失效。这导致它在 OLTP 系统里经常成为性能瓶颈而非加速器。MySQL 官方移除它，是经过多年观测后的主动放弃，不是临时调整。

替代方案必须分层考虑，没有“一招鲜”：

• 应用层缓存（最常用、最可控）
• 数据库代理层缓存（如 ProxySQL、MaxScale）
• 利用 InnoDB 缓冲池 + 合理索引（间接提升“重复查询”响应速度）
• 物化视图或冗余汇总表（针对固定报表类查询）

应用层缓存怎么接住原来 query_cache 的流量

重点不是“缓存什么”，而是“缓存多久”和“怎么失效”。原来 query_cache 是自动按 SQL 文本哈希+表变更触发失效，现在得自己管。

实操建议：

• 对读多写少、结果集稳定（比如配置表、省市区字典）的查询，用 Redis 缓存完整结果集，TTL 设为 30 分钟到几小时，不依赖 DB 层事件失效
• 对需要强一致性的查询（如用户余额），跳过缓存，直连 DB；或者用写后失效策略：UPDATE user SET balance = ? WHERE id = ? 执行完立刻 DEL redis:key:balance:{uid}
• 避免缓存动态 SQL 拼接结果（如带 ORDER BY RAND() 或时间函数），这类查询本来就不该进缓存
• 用 SQL_NO_CACHE 这种 hint 在 5.7 迁移时就该清理掉，8.0 已不识别，留着反而干扰可读性

ProxySQL 是最接近 query_cache 行为的现成方案

它工作在 MySQL 客户端和服务器之间，能基于 SQL 模式（正则）、用户、schema 做缓存，支持 TTL 和手动清除，且失效粒度可细到某张表甚至某条语句。

关键配置点：

• 启用缓存需设置 mysql-query_rules.active = 1 并添加规则，匹配语句后设置 cache_ttl（毫秒单位）
• 缓存键默认包含 username+schemaname+digest，避免不同用户间误共享
• 注意 mysql_servers 中的 max_connections 和 weight 会影响缓存穿透时的负载分担
• 不要缓存 SELECT FOR UPDATE 或含用户变量（@var）的语句，ProxySQL 不做语义分析，缓存后可能返回错误结果

InnoDB 缓冲池其实一直在“悄悄缓存”你的热数据

很多人以为没了 query_cache 就没缓存了，其实不然。InnoDB Buffer Pool 缓存的是数据页（page），不是查询结果。但如果你的重复查询能复用相同数据页，响应速度依然很快——尤其当 innodb_buffer_pool_size 足够大、索引覆盖充分时。

优化方向很实际：

• 确认 innodb_buffer_pool_size 占物理内存 50%–75%，别设成 128M 还抱怨慢
• 用 SELECT * FROM sys.schema_table_statistics_with_buffer 查看哪些表的页面最常被访问
• 把高频查询改造成覆盖索引（INDEX(a,b,c) 支持 SELECT a,b FROM t WHERE a=?），避免回表，减少 Buffer Pool 压力
• innodb_buffer_pool_dump_at_shutdown 和 inn

  

  odb_buffer_pool_load_at_startup 开启后，重启不丢热点，比 query_cache 更“耐久”

真正麻烦的不是“用什么代替 query_cache”，而是很多团队把 query_cache 当成了掩盖低效 SQL 的创可贴。8.0 移除它之后，那些 SELECT *、没走索引、全表扫描的查询，终于没法靠缓存蒙混过关了。