如何调整MySQL 5.7及以下版本的query_cache_size以配置查询缓存？

本文共计956个文字，预计阅读时间需要4分钟。

在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=20971520
query_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 直接移除查询缓存的根本原因。