Query Cache 曾是「相同 SQL 直接返结果」的尝试，但因锁竞争与失效粒度粗，已在 8.0 彻底移除。

曾经如何工作

5.7 及以前，SELECT 命中缓存则跳过解析执行；任何表写操作会使涉及该表的缓存条目失效。缓存 key 由 SQL 文本+库+字符集等构成。

为何被弃用

  • 表级失效：写多读少场景命中率极低。
  • 全局锁竞争：高并发下 cache lock 成为瓶颈。
  • 内存碎片与维护成本高于收益。

现代替代

  • 应用层/Redis 缓存热点对象。
  • InnoDB buffer pool 缓存数据页（与 SQL 文本无关）。
  • 8.0 移除后 query_cache_type 等变量不再存在。

实践建议

别在旧文档里找 query cache 调优；把精力放在 SQL 优化、合适索引与外部缓存策略。

历史调优误区

曾建议调 query_cache_size，现应彻底移除相关配置项。文档与旧博客需甄别 MySQL 版本。

应用侧缓存键设计

缓存键应含业务维度与版本，避免发布后读旧结构对象。

实践复习清单

确认 MySQL 版本无 query cache；应用缓存键规范；buffer pool 监控；缓存穿透治理；文档更新去掉过时调优项。

常见坑

  • 升级 8.0 仍配置 query_cache_size 导致启动警告或忽略。
  • 把 Redis 当 query cache 却缓存超大结果集撑爆内存。

总结与自测

为何 8.0 移除；曾经的问题；现代替代方案；应用缓存键设计注意点。升级项目检查配置残留，避免误导新人。

原理延伸

InnoDB 的核心竞争力在于把 B+ 树索引、缓冲池、redo/undo 与 MVCC 组合成可预测的 OLTP 引擎。读路径尽量走缓冲池与覆盖索引，写路径则要在行锁、日志刷盘与复制延迟之间取平衡。排查问题时不要只盯单条 SQL，还要看事务边界、锁等待、buffer pool 命中率与磁盘 fsync 延迟。性能优化永远遵循「先正确、再可测、后优化」：用慢日志和 EXPLAIN 定位瓶颈，用规范设计减少回表与锁竞争，用架构手段（读写分离、缓存、分片）承接流量，而不是在未测量前堆参数。