MySQL 8.0+ 中 query_cache_type 已被彻底删除，配置即报错且服务无法启动；其失效粒度为表级、依赖全局锁、SQL需完全一致，实际业务中几乎无法有效缓存，应转向索引优化与 InnoDB 缓冲池调优。
query_cache_type 在 MySQL 8.0 启动时报 Unknown variable 错误
这不是配置写错了，是功能被彻底删除了。MySQL 8.0 源码中已移除所有 query_cache_* 相关变量和逻辑，my.cnf 里哪怕只写一行 query_cache_type = 0，mysqld 启动时就会报 Unknown variable 'query_cache_type' 并退出。Percona Server 8.x 和 MariaDB 10.6+ 同样如此。别试图“注释掉再试”，删干净才是唯一解。
缓存失效不是偶尔发生，而是每次写操作都触发全表级清空
Query Cache 的失效粒度是表（table-level），不是查询（query-level）或行（row-level）。只要对 users 表执行一次 INSERT，所有命中过 users 的缓存项——比如 SELECT * FROM users WHERE id = 1、SELECT name FROM users LIMIT 10、SELECT COUNT(*) FROM users——全部立刻失效。在真实业务中，用户登录、订单创建、日志写入等操作每秒都在改表，缓存根本来不及热起来就被清空。这不是“命中率低”，是“压根存不住”。
LOCK_query_cache 全局锁让并发查询排队卡死
所有访问 Query Cache 的路径（查缓存、写缓存、清缓存）都必须争抢同一个互斥锁 LOCK_query_cache。这个锁不区分读写，也不支持乐观并发控制。高并发下，几十个线程同时执行 SELECT，结果不是并行响应，而是在锁上排队等待——CPU 花在上下文切换和锁竞争上，而不是查数据。这是典型的“为省一点解析时间，赔进去更多调度开销”。
SQL 字符串级匹配导致 ORM 场景几乎零命中
Query Cache 要求 SQL 完全一致：空格、换行、大小写、注释、参数值，全算在内。ORM 生成的语句天然带随机空格和注释，SELECT * FROM orders WHERE status = 'paid' 和 SELECT * FROM orders WHERE status = 'shipped' 就是两条完全不同的键。更关键的是，预编译语句（SELECT * FROM users WHERE id = ?）根本不会进入 Query Cache 流程——MySQL 解析阶段就绕开了它。所以你看到的“缓存命中”，大概率只来自 DBA 手写的固定测试 SQL。
真正要警惕的不是“怎么配缓存”，而是花时间调 query_cache_size 却忽略了 innodb_buffer_pool_size 是否合理、慢查询是否漏了索引、连接池是否在反复建连。Query Cache 的幽灵还在不少配置模板里残留，删掉它，系统反而更轻、更稳、更容易诊断。
