mysql 8.0+ 已彻底移除查询缓存模块，query_cache_size 参数不存在且配置无效；5.7及更早版本启用需同时满足query_cache_type=1/2且query_cache_size>1mb，并受严格缓存条件限制。
MySQL 8.0 之后 query_cache_size 已被彻底移除
直接说结论：如果你用的是 MySQL 8.0 或更高版本，query_cache_size 这个参数根本不存在，配置它不会生效，重启后也会被忽略。MySQL 官方在 8.0 中**完全删除了查询缓存（Query Cache）模块**，不是“默认关闭”，而是代码级移除。
MySQL 5.7 及更早版本开启查询缓存的必要条件
只有在 MySQL 5.7、5.6 等旧版本中，query_cache_size 才有意义，但光设这个值远远不够：
-
query_cache_type必须设为1（ON）或2（DEMAND），设为0（OFF）时即使query_cache_size > 0也完全不启用 -
query_cache_size必须大于1048576（即 1MB），否则 MySQL 会自动将其置为0，且不报错 - 查询必须满足严格条件才可能被缓存：比如不能含
NOW()、CURRENT_DATE()、用户变量、SELECT ... FOR UPDATE、涉及临时表或系统表等 - 任何对相关表的写操作（
INSERT/UPDATE/DELETE）都会使该表所有缓存条目失效——高并发写场景下缓存命中率极低
为什么 MySQL 最终废弃了 Query Cache
这不是一个“没调好就不好用”的功能，而是设计层面存在硬伤：
- 全局锁瓶颈：
SELECT缓存读取和写入都需获取同一把全局 mutex，高并发下严重争用 - 失效逻辑粗暴：一张表只要被修改，所有命中该表的缓存全清，哪怕只是更新一行
- 内存碎片严重：缓存块按固定大小切分，小查询浪费空间，大查询又容易失败
- 与现代硬件/架构不匹配：相比 SSD 和足够内存，反复解析、优化简单查询的开销已远小于维护缓存一致性成本
所以官方建议：升级到 8.0 后，别找替代方案去“恢复查询缓存”，应转向应用层缓存（如 Redis）、连接池预编译、或优化索引与执行计划。
检查你当前是否真有查询缓存可用
别只看配置文件，运行这条命令最可靠：
SHOW VARIABLES LIKE 'query_cache%';
如果返回空结果，说明你用的是 MySQL 8.0+；如果返回了 query_cache_size 但值为 0，再查 query_cache_type 是否为 OFF。另外注意：SHOW STATUS LIKE 'Qcache%' 的统计值在 8.0 中也已消失。
真正容易被忽略的是：很多运维文档或老教程仍在讲 query_cache_size，但没注明版本上下文——看到配置项就照抄，结果在 8.0 上白忙活半天还怀疑自己配错了。
