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和innodb_buffer_pool_load_at_startup开启后，重启不丢热点，比 query_cache 更“耐久”
真正麻烦的不是“用什么代替 query_cache”，而是很多团队把 query_cache 当成了掩盖低效 SQL 的创可贴。8.0 移除它之后，那些 SELECT *、没走索引、全表扫描的查询，终于没法靠缓存蒙混过关了。
