MySQL 8.0 已彻底移除查询缓存，query_cache_type等参数物理不存在，配置即报“Unknown system variable”错误；5.7虽保留但默认禁用，高并发下全局锁导致性能瓶颈，应设为0并重启验证。
MySQL 8.0 已彻底移除查询缓存，不存在“建议关闭”的操作空间——你无法在 8.0+ 中启用或配置 query_cache_type 或 query_cache_size，任何尝试设置它们都会被忽略甚至报错。
为什么 MySQL 8.0 配置文件里写 query_cache_type 会报错？
MySQL 8.0 启动时若在 my.cnf 或 my.ini 中出现 query_cache_type、query_cache_size 等相关参数，服务将拒绝启动，并抛出类似错误：
Unknown system variable 'query_cache_type'
这是因为这些变量已在源码中被完全删除，不是“默认关”，而是“物理不存在”。
- MySQL 5.7 是最后一个支持查询缓存的稳定版本，但默认已设为
query_cache_type = OFF - MySQL 5.6 开始默认禁用，5.7 仅保留兼容性接口，8.0 彻底移除
- 试图通过 SQL 动态设置（如
SET GLOBAL query_cache_type = 0）也会触发Unknown system variable错误
“全局锁瓶颈”在 5.7 及更早版本中真实存在吗？
是的，且影响直接可测。查询缓存的失效机制依赖一个全局互斥锁（Query Cache Lock），只要任意线程执行了涉及某张表的 INSERT、UPDATE 或 DELETE，该锁就会被争抢以批量清除所有关联缓存项。
- 高并发写入场景下，
Qcache_locks状态值会急剧上升，Qcache_hits却极低（实测常低于 2%） - 使用
SHOW STATUS LIKE 'Qcache%';查看时，若Qcache_inserts远大于Qcache_hits，说明缓存几乎没被复用，但锁开销照常发生 - 即使只有一张表高频更新，整个查询缓存模块都会成为串行化瓶颈，多核 CPU 利用率反而不均衡
如果你还在用 MySQL 5.7，应如何安全停用查询缓存？
不要留任何侥幸：哪怕业务看似“读多写少”，只要存在定时任务、日志写入或用户行为埋点等隐式更新，查询缓存就大概率拖慢整体 QPS。
- 在
[mysqld]段落中明确设置：query_cache_type = 0和query_cache_size = 0 - 重启 MySQL 后验证：
SHOW VARIABLES LIKE 'query_cache%';应全部返回OFF或0 - 避免在 SQL 中使用
SQL_CACHE或SQL_NO_CACHE提示——它们在 8.0+ 已失效，在 5.7 中也仅对开启状态生效，徒增语法负担 - 压测对比：关闭前后用相同负载测试，重点关注
Threads_running峰值和innodb_row_lock_waits是否下降
真正需要警惕的，不是“要不要关查询缓存”，而是是否还在用 5.7 并误以为它能加速现代 Web 应用——它的缓存粒度、失效逻辑和锁模型，与 ORM 自动生成的带参数查询、前端轮询、实时聚合等常见模式天然冲突。替代方案（如 Redis 缓存 SELECT * FROM user WHERE id = ? 这类确定性查询）可控、可监控、可分级失效，远比寄希望于一个字节级匹配的全局缓存靠谱得多。
