必须删除my.cnf中所有以query_cache_开头的行（含注释），因mysql 8.0.3起该变量已源码级删除，保留即启动失败；其表级失效、全局锁争用和字节级匹配等缺陷导致高并发下性能反降。
MySQL 8.0 启动报 Unknown system variable 'query_cache_type' 怎么办
这不是配置写错了，是变量真没了。MySQL 8.0.3 起，query_cache_type、query_cache_size、query_cache_limit 等所有相关变量和逻辑已被源码级删除。mysqld 解析配置时遇到这些名字，直接报错退出，不会跳过、不会忽略、不兼容降级。
必须手动删掉 my.cnf（或 my.ini）中所有以 query_cache_ 开头的行——包括注释掉的，比如 # query_cache_type = 1 也得删。某些配置解析器会误判注释行，导致启动失败。
验证方式很简单：mysqld --validate-config 可提前检查，比等服务崩溃再翻日志更高效。
为什么 UPDATE 一行就让整张表的缓存全失效
Query Cache 的失效粒度是表级（table-level），不是语句级，更不是行级。只要对 users 表执行任意 INSERT/UPDATE/DELETE，所有命中该表的缓存条目——无论 SQL 多具体——全部立刻清空。
SELECT name FROM users WHERE id = 1SELECT COUNT(*) FROM usersSELECT * FROM users LIMIT 10
上面三条语句共享同一个失效触发点。真实业务中，用户登录、订单创建、日志写入每秒都在改表，缓存根本热不起来就被清空。这不是“命中率低”，是“存不住”。
为什么高并发下 Query Cache 反而拖慢 QPS
核心瓶颈是那把全局锁 LOCK_query_cache：所有 SELECT 检查缓存、所有 DML 清空缓存，都得排队等它。这个锁不分读写、不可降级、无法分片。
常见现象：
-
SHOW PROCESSLIST里大量线程显示Waiting for query cache lock - CPU %system 升高，上下文切换频繁，但实际 SQL 执行时间占比很低
- Percona 实测：200+ QPS 写入场景下，开启 Query Cache 的吞吐比关闭时低 15%～30%
哪怕只是检查 SELECT * FROM users WHERE id = 123 在不在缓存里，也要抢锁；而一次 UPDATE 不仅清缓存，还要持锁重建哈希结构——开销远超收益。
为什么缓存命中率常年低于 5% 却还在吃资源
Query Cache 要求 SQL 字节级完全一致：空格、换行、大小写、注释、客户端字符集、SQL mode 差一点，就是不同 key。ORM（Django/MyBatis/Sequelize）生成的语句天然带随机空格和注释，基本不命中。
更关键的是，以下语句压根不进缓存路径：
- 预处理语句（
PREPARE/EXECUTE） - 含
NOW()、RAND()、用户变量（@var）、子查询或临时表的查询 - 分区表上的查询（默认禁用）
结果就是：Qcache_hits / Com_select 比值常年低于 0.1，但哈希计算、内存查找、锁争用这些 CPU 和内存开销照常发生——实测 CPU usage 升高 13%～18%。
真正该花时间调的，从来不是 query_cache_size，而是 innodb_buffer_pool_size 是否合理、慢查询是否漏了索引、连接池是否在反复建连。Query Cache 的幽灵还在不少旧配置模板里残留，删掉它，系统反而更轻、更稳、更容易诊断。
