MySQL 8.0 移除 Query Cache 后性能提升，因其全局锁导致高并发下严重争抢、缓存频繁失效且粒度粗，而资源被释放给 InnoDB 缓冲池、应用层缓存等更高效机制。
MySQL 8.0 取消 Query Cache 后性能更高，不是因为“缓存没了所以快了”，而是因为移除了一个在高并发下持续抢锁、频繁失效、还吃内存的全局瓶颈。
Query Cache 的全局锁是并发杀手
只要执行一条 UPDATE、INSERT 或 DELETE，Query Cache 就要获取一个全局互斥锁来清空所有关联表的缓存条目。这个锁会阻塞所有正在尝试读取或写入缓存的查询线程——哪怕只是两个并发 SELECT，也可能因争抢这把锁而排队等待。在真实业务中，每秒几十次写操作很常见，结果就是缓存区长期处于“刚建好就清空”的状态，CPU 时间全耗在锁调度上，而不是查数据。
- MySQL 5.7 中即使开启
query_cache_type = 1，只要写入稍有压力，Qcache_hits基本归零，Qcache_lowmem_prunes却飙升 - Percona 测试显示：在 200+ QPS 写入场景下，启用 Query Cache 的吞吐比关闭时低 15%～30%
- 这个锁无法拆分、无法绕过，是硬编码在 query cache 模块里的设计死结
缓存失效粒度太粗，命中率天然不可靠
Query Cache 不按 SQL 参数、不按 WHERE 条件、甚至不按表分区失效，而是“一张表被改，所有涉及该表的 SELECT 缓存全废”。这意味着：SELECT * FROM users WHERE id = 1 和 SELECT name FROM users WHERE id = 1000 会因同一行 UPDATE users SET updated_at = NOW() 而同时失效——完全无视实际影响范围。
- 它只认“表名”，不认 MVCC 版本、不认事务隔离级别、不认索引覆盖程度
- 预处理语句（
PREPARE/EXECUTE）默认不走 Query Cache，而现代 ORM（如 Django、MyBatis、Sequelize）几乎全用预处理 - 哪怕你手动加
SQL_CACHE，只要语句里带NOW()、RAND()、用户变量或子查询含临时表，立刻被拒之门外
MySQL 8.0 把资源让给了真正可扩展的机制
删掉 Query Cache 不是“放弃缓存”，而是把内存、CPU、锁管理逻辑腾出来，交给更可控、更细粒度、更贴近现代负载的组件：
-
innodb_buffer_pool_size成为唯一核心缓存开关：它缓存的是页（page），不是结果集；支持并发读、MVCC 多版本、LRU 链表淘汰，且无全局锁 - 应用层缓存（Redis / Memcached）由业务控制生命周期：可按 key 粒度失效、支持 TTL、能穿透更新、配合布隆过滤器防击穿
- 查询重写与物化视图（MySQL 8.0+ 支持
CREATE TABLE ... AS SELECT+ 定时刷新）更适合稳定聚合场景，比 Query Cache 更可靠
最常被忽略的一点：Query Cache 的存在，会让 DBA 误判性能问题根源——看到 Qcache_hits 很低，第一反应是“调大 query_cache_size”，而不是去查 slow_query_log 或优化索引。它的移除，倒逼出更健康的性能分析习惯。
