MySQL查询缓存可提升5.7及更早版本的查询性能，通过将SELECT结果存入内存实现快速响应，但8.0起已移除；其启用需配置query_cache_type、size等参数，且仅完全相同SQL（含大小写和空格）且不含动态函数的结果可被缓存；INSERT/UPDATE/DELETE操作会清空相关表缓存，导致高并发写入时命中率低；此外存在锁竞争与内存碎片问题，官方推荐使用Redis等外部缓存替代。
MySQL查询缓存是一种将SELECT查询结果保存在内存中的机制，当相同的查询再次执行时，可以直接从缓存中返回结果，避免重复解析、优化和执行，从而提升性能。但需要注意的是，从MySQL 8.0版本开始，查询缓存功能已被彻底移除，因此以下内容适用于MySQL 5.7及更早版本。
启用并配置查询缓存
要使用查询缓存，首先要确认其已启用，并根据实际负载合理设置参数：
- query_cache_type = ON：开启查询缓存（可选值为ON、DEMAND、OFF）
- query_cache_size = 64M：设置分配给查询缓存的总内存大小，太小无效，太大可能造成内存碎片
- query_cache_limit = 2M：限制单条查询结果可缓存的最大大小，超过则不缓存
- query_cache_min_res_unit = 4k：每个缓存块的最小存储单元，调整它可减少内存碎片
可通过以下命令查看当前状态：
SHOW VARIABLES LIKE 'query_cache_%';SHOW STATUS LIKE 'Qcache%';
哪些查询能被缓存
并非所有SELECT语句都能被缓存，只有满足特定条件的查询才会进入缓存：
- 查询必须是完全相同的SQL字符串（包括空格、大小写）
- 不能包含动态函数，如NOW()、CURRENT_DATE()、RAND()等
- 不能涉及用户自定义函数或存储函数
- 不能对带有触发器的表进行查询
- 查询的表在缓存期间未被修改（INSERT、UPDATE、DELETE等操作会清空对应表的缓存）
例如，下面两个查询被视为不同，不会命中同一缓存：
SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id=1;
提高查询缓存命中率的技巧
为了最大化利用查询缓存，可以采取以下优化措施：
- 统一SQL书写格式，使用预编译语句或ORM时注意生成一致的SQL
- 避免在查询中使用不确定函数，如需时间信息，可在应用层获取后传入
- 频繁读取且很少更新的表更适合使用查询缓存，如配置表、字典表
- 监控Qcache_hits与Qcache_inserts的比例，理想情况下命中率应较高
- 定期分析Qcache_lowmem_prunes，若数值偏高说明缓存空间不足或碎片严重，需调大query_cache_size
注意事项与替代方案
尽管查询缓存在某些场景下有效，但它存在明显局限：
- 表一旦更新，所有涉及该表的缓存都会失效，高并发写入环境下缓存命中率极低
- 锁竞争严重，特别是在多核系统上，查询缓存的全局锁可能成为瓶颈
- 内存管理效率不高，容易产生碎片
正因如此，MySQL官方建议使用外部缓存（如Redis、Memcached）或应用层缓存来替代查询缓存。通过在应用中缓存热点数据，可以更灵活地控制缓存生命周期和粒度。
基本上就这些。如果你还在使用MySQL 5.7或更早版本，合理配置查询缓存可能带来一定性能提升，但需结合实际业务权衡利弊。对于新项目，建议直接采用更高效的缓存架构。
