MySQL 的查询缓存并不是银弹，它更适合读多写少、SQL 高度重复的环境。了解它的存储方式和匹配规则，是判断要不要启用、以及怎样设置参数的前提。简单来说，查询缓存以 SELECT 语句的完整文本作为键，结果集作为值保存在内存中。客户端发起查询时，MySQL 会先做大小写敏感的逐字节比较，只有完全相同的 SQL 文本才能命中缓存。任何细微差异，例如多一个空格、表的别名不同、甚至客户端字符集不一致，都会导致无法命中。
所以配置查询缓存之前，需要确认业务 SQL 是否真的具备高重复性。对于 ORM 自动生成的 SQL，如果参数拼接顺序稳定，可能命中；如果每次生成的 SQL 文本不同，查询缓存基本无效。查询缓存还会跳过包含非确定性函数的语句，比如 NOW()、RAND()，以及使用了临时表、视图的查询。这些限制常常被忽略，导致缓存命中率不如预期。
核心参数配置与含义
MySQL 查询缓存由一组系统变量控制，其中最重要的四个参数是 query_cache_type、query_cache_size、query_cache_limit 和 query_cache_min_res_unit。第一个参数决定缓存的工作模式：0 或 OFF 表示关闭，1 或 ON 表示开启所有可缓存的查询，2 或 DEMAND 表示按需缓存，只有显式带上 SQL_CACHE 关键字的 SELECT 才会进入缓存。生产环境通常建议使用 2，避免无差别缓存那些命中率极低的 SQL，从而减少缓存管理的资源消耗。
query_cache_size 设定缓存使用的总内存量，单位可以是字节或带单位的字符串，例如 64M。这个值设为 0 也等同于关闭查询缓存。分配的内存并不是越大越好，过大的缓存区域会导致内部碎片增多、维护链表的时间增加，甚至在高并发下引发全局锁竞争。一般从 32M 到 256M 之间开始测试比较稳妥。query_cache_limit 则限制单个查询结果集能够缓存的最大体积，超过这个体积的结果不会写入缓存，防止大查询挤占整个缓存空间。
query_cache_min_res_unit 是查询缓存分配内存时的最小块大小，默认值是 4096 字节。如果业务中大量返回小结果集，可以把这个值调小，例如 512 或 1024，以减少内存浪费；反之，如果结果集普遍较大，可以适当调大，减少内存块的数量。下面的配置示例适合中等规模的读多写少业务，通常写在 MySQL 配置文件里。若使用 Windows 系统，配置文件路径一般是 C:\ProgramData\MySQL\MySQL Server 5.7\my.ini，修改后需要重启 MySQL 服务才会生效。
[mysqld] query_cache_type = 2 query_cache_size = 64M query_cache_limit = 2M query_cache_min_res_unit = 512
修改配置并重启后，可以通过以下 SQL 查看参数是否已经生效，同时观察查询缓存的运行状态。
SHOW VARIABLES LIKE 'query_cache%'; SHOW STATUS LIKE 'Qcache%';
状态变量中，Qcache_free_memory 表示当前剩余缓存内存，Qcache_hits 表示缓存命中次数，Qcache_inserts 表示写入缓存的次数，Qcache_lowmem_prunes 表示因内存不足而被淘汰的缓存条目数量。如果 Qcache_lowmem_prunes 持续增长，说明分配的 query_cache_size 偏小，可以适当调大；如果 Qcache_free_memory 一直很高，说明缓存空间用不完，没必要继续加大。
查询缓存的工作机制与失效场景
查询缓存的匹配过程比很多人想象的要严格。MySQL 会在解析 SQL 之前先检查查询缓存，把客户端发来的原始 SQL 文本与缓存中的键进行比对。这个比对是大小写敏感的，同时还会受到当前数据库、字符集、协议版本等因素影响。因此 SELECT * FROM users WHERE id = 1 和 select * from users where id = 1 在查询缓存看来是两条完全不同的 SQL，后者无法命中前者缓存的结果。这一点对使用 ORM 框架的项目尤其重要，框架生成的 SQL 文本必须保持稳定，否则缓存形同虚设。
更需要注意的是查询缓存的失效机制。它采用表级失效策略，也就是说，只要某张表上发生了 UPDATE、DELETE 或 INSERT 操作，那么所有引用这张表的缓存条目都会立即失效并被清除。这个过程不是异步的，而是写操作发生时同步完成。对于写入频繁的表，比如订单表、库存表，缓存可能刚写入就被清掉，命中率会非常低，而每次清空操作还会消耗额外的 CPU 时间。如果同时有大量并发写操作，查询缓存内部的全局锁还可能成为新的瓶颈。
还有一个容易忽略的参数 query_cache_wlock_invalidate，它控制当表被写锁锁定时，是否让对应的缓存条目失效。默认情况下该参数为 OFF，表示即使表上有写锁，其他会话读取该表时仍然可以命中旧的缓存结果。在要求严格数据一致性的场景下，可能需要把它设置为 ON，不过这样会进一步降低缓存的可用性。总体来说，查询缓存只适合那些表数据很少变化、但同一批 SQL 被反复执行的场景。
性能评估与常见误区
很多团队在开启查询缓存后，只关注命中率这个单一指标，这其实是一个常见误区。命中率可以用 Qcache_hits 除以 Qcache_hits 与 Com_select 之和来估算，但即使命中率达到 80%，也不代表性能一定提升了。因为查询缓存的命中本身也需要进行哈希查找和内存拷贝，如果结果集很大，命中花费的时间可能并不比重新执行查询少多少。同时，写入操作触发缓存失效时会带来额外开销，这部分成本在 Com_select 中无法体现。
另一个误区是给查询缓存分配过大的内存。虽然更大的 query_cache_size 可以容纳更多条目，但查询缓存内部有全局锁来保护内存结构，当大量连接同时命中或写入缓存时，这个锁可能成为竞争热点。在几十个甚至上百个并发连接下，过大的缓存区域反而会拖慢整体吞吐量。通常建议从小内存开始测试，观察 Qcache_lowmem_prunes 和 CPU 使用率的变化，再决定是否继续增加。
要评估查询缓存是否真正有效，可以对比开启和关闭状态下的平均响应时间、TPS 以及 CPU 负载。如果开启后写操作的延迟明显上升，或者 CPU 使用率增加而吞吐量没有提升，就说明当前业务不适合使用查询缓存。下面这条 SQL 可以在开启 DEMAND 模式后，只对指定查询使用缓存，方便做小范围测试：
SELECT SQL_CACHE id, nickname FROM users WHERE id = 100;
执行该语句后，再通过 SHOW STATUS LIKE 'Qcache_hits' 查看命中数是否增加，并结合实际响应时间判断缓存效果。这种按需缓存的方式比全局开启更可控，也更适合混合读写场景。
替代方案与优化建议
从 MySQL 8.0 开始，官方已经彻底移除了查询缓存功能，原因是它带来的性能提升有限，却给内核维护和并发处理增加了不少复杂度。如果你正在使用 MySQL 8.0 或更高版本，就不能再依赖原生查询缓存，需要寻找其他方案。对于读多写少的业务，最直接的替代做法是引入应用层缓存，例如 Redis 或 Memcached，把查询结果以 JSON 或其他序列化格式存放在缓存中间件中，由应用代码负责缓存的读取和失效逻辑。
应用层缓存的优势在于粒度可以更细，可以精确到某一个对象的某个字段，而不是像 MySQL 查询缓存那样只能按整表失效。此外，应用层缓存不会阻塞数据库写入操作，也不需要数据库内核维护额外的内存结构。但代价是需要额外开发缓存更新和失效策略，例如缓存穿透、缓存雪崩、数据一致性等问题。对于不太方便改动代码的项目，也可以考虑在代理层做缓存，例如使用 ProxySQL 提供的查询缓存功能，它可以根据规则对某些 SELECT 语句的结果进行缓存，并且支持设置缓存过期时间。
如果既不想引入额外组件，又想减少数据库压力，可以先从 SQL 优化和索引设计入手。很多时候查询慢并不是因为没有命中缓存，而是 SQL 本身执行效率低、索引不合适或者返回了不必要的列。通过 EXPLAIN 分析执行计划，消除全表扫描，减少回表次数，往往能获得比查询缓存更稳定、更可预期的性能提升。对于确实需要缓存的热点数据，也可以使用 MySQL 的 MEMORY 存储引擎或临时表来手动实现，但这只适合非常小的数据集，不适合大规模使用。
总之，查询缓存是在特定历史条件下出现的优化手段，它的适用面比较窄。配置时不能只把参数打开就完事，需要结合表的更新频率、SQL 文本稳定性以及并发压力来综合判断。对于 MySQL 5.x 版本，可以按本文介绍的参数逐步调优，并持续观察状态变量；对于 MySQL 8.0 及以上版本，则应优先考虑应用层缓存或其他替代方案。理解查询缓存的工作机制和失效代价，比盲目开启更重要。
MySQL查询缓存query_cache_size查询缓存优化修改时间：2026-09-27 03:31:53