MySQL 查询缓存原理、配置与性能调优指南

工作原理

MySQL 查询缓存的核心机制是缓存 SELECT 操作（含预处理查询）的结果集与原始 SQL 语句。当新的 SELECT 请求到达时，系统会首先核对缓存：要求新语句与缓存中的 SQL 必须完全一致（区分大小写）。若匹配成功，直接返回结果，跳过后续的语法解析和执行过程。

然而，并非所有查询都能享受此加速效果。以下几类语句因不确定性或权限限制，无法被缓存：

• 显式禁用：包含 SQL_NO_CACHE 参数的查询。
• 动态函数：涉及非确定值函数的语句，如 CURDATE()、RAND()、GET_LOCK()、CONVERT_TZ() 及自定义函数。
• 内部库查询：针对系统数据库 mysql 和 information_schema 的查询。
• 变量引用：使用 SESSION 级变量或存储过程局部变量的查询。
• 锁模式：使用了 LOCK IN SHARE MODE 或 FOR UPDATE 的语句。
• 导出操作：类似 SELECT ... INTO 的数据导出语句。
• 事务隔离：在 Serializable 级别下，所有查询均不可缓存。
• 临时表与警告：对临时表的查询，或执行过程中产生警告信息的语句。
• 无表查询：不涉及任何表或视图的纯常量查询（如 SELECT 1）。
• 权限限制：用户仅拥有列级别权限的查询。

优缺点评估

查询缓存在特定场景下优势明显，但也带来不可忽视的开销：

优点：对于完美匹配的重复查询，无需进行 SQL 解析和执行计划生成，直接从内存中读取结果集，极大提升了响应速度。

缺点：

• 比对成本高：判断规则不够智能，严格的字符匹配导致维护成本增加。
• 写入阻塞：只要涉及的某张表发生变动，系统必须清理该表对应的所有缓存。由于每张表对应一个全局锁，频繁的 DML（增删改）操作会导致严重的锁等待，抵消读取加速带来的收益。

配置参数详解

要启用或调整查询缓存，需关注以下核心参数。若 query_cache_type 或 query_cache_size 任一值为 0，则功能关闭。通常建议将 query_cache_type 设为 0 以手动控制，或通过具体数值开启。

第 1 步：设置基础开关 (query_cache_type)

入口：配置文件 my.cnf 或动态修改。

• 0：不启用查询缓存。
• 1：全局启用。凡符合规则的客户端查询均会被缓存。
• 2：按需启用。仅在 SQL 中包含 SQL_CACHE 提示符时才尝试缓存。

第 2 步：分配内存空间 (query_cache_size)

最小值为 40KB。生产环境中，盲目增大此值并不能提高命中率，反而可能增加内存碎片和管理开销。建议初始设置为 64MB，并根据实际运行数据微调。

第 3 步：限制单条记录大小 (query_cache_limit)

默认 1MB。为避免大结果集占用过多内存，建议根据应用预估的小查询结果集大小进行调整，推荐范围在 16KB ~ 1024KB 之间。

第 4 步：优化内存块分配 (query_cache_min_res_unit)

定义分配内存的最小单位。默认 4KB。设置过小会增加内存申请次数，过大则易产生内存碎片。建议在系统平稳运行后，依据公式计算最佳值，推荐范围 1KB ~ 16KB。

第 5 步：处理 MyISAM 写锁冲突 (query_cache_wlock_invalidate)

主要针对 MyISAM 引擎。默认值 0 表示允许其他客户端在有写锁时继续从缓存读取旧数据。若设为 1，则在表被加写锁时，相关的缓存将被失效，保证强一致性但牺牲读取性能。

维护与碎片整理

随着读写操作的进行，查询缓存极易产生内存碎片。为了维持高效运行，需定期执行维护命令：

1. 整理碎片：FLUSH QUERY CACHE;
   将已缓存的查询结果移至缓存区的一端，压缩空白区域，恢复可用连续内存。
2. 清空缓存：RESET QUERY CACHE;
   移除所有缓存条目，但保留已分配的内存空间。也可通过 FLUSH TABLES; 间接触发。

性能监控与调优策略

判断缓存配置是否合理，主要依赖以下状态变量： Qcache_hits, Qcache_inserts, Qcache_free_memory, Qcache_total_blocks, Qcache_free_blocks, Qcache_lowmem_prunes。

第 1 步：计算关键指标

• 碎片率：(Qcache_free_blocks / Qcache_total_blocks) * 100%
• 命中率：((Qcache_hits - Qcache_inserts) / Qcache_hits) * 100%
• 内存使用率：((query_cache_size - Qcache_free_memory) / query_cache_size) * 100%

第 2 步：根据监控数据决策

在系统平稳运行至少一周后，观察以下两种典型情况：

场景 A：内存不足
特征：命中率 > 80%，内存使用率 > 80%，且 Qcache_lowmem_prunes（因内存不足被剔除的条目数）持续增长。
对策：说明分配的空间过小，应适当增加 query_cache_size。

场景 B：效果不佳或资源浪费
特征：命中率 < 40%，Qcache_lowmem_prunes 保持平稳，且观察到 freeing items。
对策：说明业务场景中重复查询概率低，或频繁更新导致缓存失效过快。此时应考虑减小内存甚至彻底关闭查询缓存，以避免其带来的锁竞争和 CPU 开销。

动态调整最小内存块
若在运行中发现碎片率过高，可参考以下公式重新设置 query_cache_min_res_unit：
(query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

适合的业务场景

综合上述分析，MySQL 查询缓存最适合以下特征的“读多写少”业务：

• 静态内容为主的系统：如门户网站、新闻发布系统、技术文档库、论坛帖子浏览等。
• 低频更新的表：操作对象主要为历史数据或基础字典表，极少进行 INSERT、UPDATE 或 DELETE。
• 配置建议：对于此类场景，可配合 query_cache_type=2，并在特定的高频只读 SQL 语句中加入 SQL_CACHE 标签，以实现精细化的性能掌控。

以上就是 MySQL 查询缓存原理、配置参数与性能调优的详细内容，更多关于数据库性能优化的资料请关注本站其它相关文章！