MySQL 5.7 中 query_cache_type = 1 不是加速器而是全局锁瓶颈，因每次查询需争抢 query_cache_lock，写操作触发全表缓存清空，导致命中率低于5%、锁等待飙升；真正关闭须删光配置文件中所有 querycache* 参数并重启mysqld，仅 SET GLOBAL 关闭无效。
query_cache_type = 1 在 5.7 里不是加速，是全局锁瓶颈
MySQL 5.7 默认开启 query_cache_type = 1，但它根本不是“缓存”，而是一个高竞争的全局互斥点。每次查询前都要抢一把全局 mutex 锁（query_cache_lock），写操作（哪怕只是 INSERT INTO log_table）又会触发全表缓存清空逻辑——结果就是：缓存命中率常低于 5%，锁等待却持续上升。
常见错误现象：
-
perf top -p $(pgrep mysqld)频繁出现query_cache_lock符号 -
SHOW STATUS LIKE 'Qcache%'中Qcache_lowmem_prunes远高于Qcache_hits - Threads_connected 持续上涨，但 Queries 每秒处理量不增反降
为什么 SET GLOBAL query_cache_type = OFF 不算真正关闭
运行时执行 SET GLOBAL query_cache_type = OFF 只是临时停用，MySQL 重启后会重新读取配置文件里的残留参数，并自动把 query_cache_type 拉回 1——只要 query_cache_size 被设为非零值，5.7 就认定“你要用”，哪怕你没写 query_cache_type 这行。
必须做三件事：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 在
my.cnf或mysqld.cnf的[mysqld]段中，删掉或注释掉所有query_cache_*行：query_cache_type、query_cache_size、query_cache_limit、query_cache_min_res_unit - 重启 MySQL（
systemctl restart mysqld），仅 reload 配置不生效 - 确认
SHOW VARIABLES LIKE 'query_cache%'全部返回OFF或0
5.7 后期版本中 query_cache_type 已失效，但监控还在骗人
从 5.7.20 开始，查询缓存被标记为 deprecated；5.7.33+ 和全部 8.0 版本已彻底移除代码路径。但部分 5.7.x 小版本仍保留变量注册逻辑，导致 SHOW VARIABLES LIKE 'query_cache_type' 显示 ON，而 SHOW STATUS LIKE 'Qcache%' 全是 0——这不是配置错了，是缓存入口函数已被绕过。
验证是否真失效：
- 执行
SELECT @@query_cache_type, @@query_cache_size - 再执行两次相同
SELECT * FROM t LIMIT 1 - 查
SHOW STATUS LIKE 'Qcache_hits'，若没增长，说明缓存没工作 - 注意：
have_query_cache恒为YES，它只表示编译时含旧代码，不能当功能可用依据
禁用后仍要小心残留配置干扰其他缓存指标
最易被忽略的是：即使你从没主动配过 QueryCache，只要 my.cnf 里留着 query_cache_size = 1048576 这类残留，5.7 就会悄悄启用缓存逻辑，占用内存并参与锁竞争——而你可能正盯着 Key_reads 或 Innodb_buffer_pool_reads 排查性能问题，完全没意识到 query_cache 在背后拖累。
真正干净的做法是：删光所有 query_cache_* 配置项，重启，再验证。别信变量显示，看 Qcache_inserts 和 Qcache_hits 是否为 0，这才是唯一可信信号。
