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