mysql 5.7及更早版本中，query_cache_size=0即彻底禁用查询缓存，不分配内存且跳过缓存判断逻辑；需同时设query_cache_type=0并重启服务才完成关闭。
query_cache_size 设置为 0 就等于关闭缓存
MySQL 5.7 及更早版本中，query_cache_size 是决定查询缓存是否真正启用的关键参数。即使 query_cache_type 设为 ON 或 1，只要 query_cache_size 是 0，查询缓存就完全不工作——连内存都不分配。
常见误操作是只改了 query_cache_type，却忽略 query_cache_size 仍为默认的 0，导致以为开了缓存，实际完全没生效。
-
query_cache_size=0：强制禁用，不管type是什么值 -
query_cache_size=1048576（1M）：最小有效值，低于此值 MySQL 启动时会自动设为0 - 建议初值设为
20971520（20M），再根据Qcache_free_memory和Qcache_lowmem_prunes监控调整
为什么不能盲目调大 query_cache_size
过大的 query_cache_size 不仅浪费内存，还会加剧锁竞争和碎片问题。查询缓存使用全局互斥锁（single mutex）管理，高并发下多个线程争抢同一把锁，反而拖慢整体查询速度。
典型症状包括：Qcache_lowmem_prunes 持续升高、Qcache_free_blocks 数量多但 Qcache_free_memory 不足（说明碎片严重）、Qcache_hits / Qcache_inserts 比值低于 0.5。
- 超过 256MB 基本无收益，官方文档明确建议上限为 256M
- 若应用写操作频繁（如每秒多次
UPDATE），哪怕缓存设得再大，Qcache_hits也会极低 - MyISAM 表比 InnoDB 更容易从查询缓存获益，因为 InnoDB 的 MVCC 和行级锁让缓存失效更频繁
修改后必须重启 mysqld 才生效
query_cache_size 是静态变量，无法通过 SET GLOBAL 动态修改。改完配置文件后必须完整重启服务，否则新值不会加载。
操作顺序要严格：
- 编辑
/etc/my.cnf，在[mysqld]段下添加或修改两行：query_cache_size=20971520query_cache_type=1 - 执行
service mysql restart（或systemctl restart mysqld） - 登录后验证：
SHOW VARIABLES LIKE 'query_cache%';确认两个值都已更新 - 不要跳过验证步骤——配置文件语法错误或段落位置不对（比如写到
[client]下）会导致设置静默失败
query_cache_size 不是越大越好，关键看 Qcache_lowmem_prunes
真正衡量缓存大小是否合适的指标是 Qcache_lowmem_prunes：它表示因内存不足而被迫淘汰缓存条目的次数。如果该值持续增长，说明当前 query_cache_size 不够；但如果增长过快（比如每秒数次），往往不是缓存太小，而是缓存本身不适合这个负载场景。
此时应优先检查业务逻辑：
- 是否存在大量带
NOW()、CURRENT_DATE等非确定函数的查询？这些根本不会进缓存 - SQL 是否存在空格、大小写、注释等微小差异？缓存对字符串完全敏感，
SELECT * FROM t和select * from t是两个缓存项 - 表是否频繁更新？一次
UPDATE就会让整个表相关的所有缓存全部失效
缓存机制本身很“脆弱”——它依赖 SQL 文本完全一致 + 表数据长期不变这两个强前提。现实中满足条件的场景正在快速减少，这也是 MySQL 8.0 直接移除查询缓存的根本原因。
