MySQL 5.7 查询缓存必须禁用，因其在5.7.33+已废弃、全局锁拖慢性能；需在my.cnf中彻底删除所有query_cache_*配置，设query_cache_type=0且query_cache_size=0，重启后验证两者均为0且SHOW STATUS LIKE 'Qcache%'返回空。
MySQL 5.7 的查询缓存（Query Cache）在绝大多数生产场景下不仅不能提升性能，反而会成为严重瓶颈；安全禁用它不是“可选项”，而是必须立即执行的操作。
确认 query_cache_type 确实已失效或被废弃
别信 my.cnf 里写了 query_cache_type = 0 就万事大吉。MySQL 5.7.20 起默认禁用，5.7.33 起源码中已移除 Query Cache 实现逻辑——此时 query_cache_type 变成只读变量，设成 1 也返回 0。
- 执行
SELECT @@query_cache_type;，若返回0，说明已被忽略或废弃 - 再执行
SHOW STATUS LIKE 'Qcache%';，若结果为空或全为 0，证明缓存模块根本没加载 - 查版本：
SELECT VERSION();，若 ≥5.7.33，直接跳过所有调参，只做禁用动作
在 my.cnf 中正确写入禁用配置
禁用必须同时关闭类型和内存分配，否则残留的 query_cache_size > 0 仍会触发锁竞争和内存管理开销。
- 编辑实际生效的配置文件（宝塔用户是
/www/server/mysql/etc/my.cnf，Docker 用户需挂载到/etc/mysql/conf.d/下） - 在
[mysqld]段内添加两行（不要写在其他段，不要加引号）：query_cache_type = 0<br>query_cache_size = 0
- 删掉任何类似
query_cache_limit、query_cache_min_res_unit的冗余配置——它们已无意义
重启后验证是否真正禁用
改完不重启=白改；重启后不验证=可能还在假运行。
- 重启服务：
systemctl restart mysqld（宝塔）或docker restart mysql（容器） - 登录 MySQL 执行：
SELECT @@query_cache_type, @@query_cache_size;，必须同时返回0和0 - 检查状态：
SHOW STATUS LIKE 'Qcache%';应返回空结果集（不是数值为 0） - 观察错误日志：
tail -n 20 /var/log/mysqld.log，确认无Query cache is disabled类警告（有则说明旧版残留逻辑仍在尝试初始化）
禁用后性能提升的关键不在“关缓存”，而在释放资源
禁用 Query Cache 的真实收益，是让出那把全局互斥锁 Qcache_lock 和避免内存碎片恶化——但这只是起点。
- 必须同步调大
innodb_buffer_pool_size（建议占物理内存 50%–75%，如 4GB 机器设为2G），把原来被 Query Cache 占用的内存转给真正有效的缓冲池 - 高并发写入场景下，
Qcache_lowmem_prunes曾每分钟数百次，禁用后该值归零，但Innodb_buffer_pool_wait_free可能上升——这时要检查innodb_buffer_pool_instances是否合理（≥ 8） - ORM 自动生成的 SQL 很难命中 Query Cache，禁用后反而消除了“看似缓存了、实则全 miss”的误导性指标，让慢查询优化更聚焦真实瓶颈
真正容易被忽略的是：即使你成功设了 query_cache_type = 0，只要配置文件里还留着 query_cache_size = 16M 这类参数，MySQL 5.7.20+ 仍会在启动时尝试初始化缓存结构，徒增毫秒级延迟和内存扫描开销——所以必须清空所有相关配置项，一个不留。
