# 35. MySQL 的查询缓存（Query Cache）是如何工作的？为什么 MySQL 8.0 移除了 Query Cache？ # 标准答案（面试版） MySQL的查询缓存（Query Cache）是一个将SELECT查询结果与SQL语句文本关联存储的内存区域，目的是加速重复查询。
工作原理：
接收到SELECT查询后，计算查询文本的哈希值 检查缓存中是否存在完全相同的查询 如果命中，直接返回缓存的结果集，跳过解析、优化和执行阶段 如果未命中，正常执行查询并将结果存入缓存 为什么MySQL 8.0移除了Query Cache：
扩展性差：全局锁设计导致高并发下性能急剧下降 命中率低：任何表结构或数据变化都会使相关表的所有缓存失效 内存管理效率低：频繁的内存碎片整理和缓存失效操作消耗资源 维护成本高：代码复杂度高，与其他MySQL组件耦合紧密 替代方案更优：ProxySQL、应用层缓存、内存数据库等提供更灵活的缓存解决方案 MySQL团队认为Query Cache的设计存在根本性缺陷，无法通过优化解决，因此在8.0版本中彻底移除，建议用户采用其他缓存技术。
# 图解分析（解析版） # 1. 查询缓存的基本架构 MySQL的查询缓存是一项早期设计的优化功能，目的是避免重复执行相同的查询语句。它是一个位于解析器之前的内存结构，用于存储SELECT查询的结果集。
[插图1：Query Cache在MySQL架构中的位置]
查询缓存在MySQL处理流程中的位置非常靠前，这使得命中缓存的查询能够完全跳过语法解析、优化和执行阶段，直接返回结果，理论上可以显著提高查询性能。
查询缓存的基本数据结构是一个哈希表，键是规范化后的SQL查询文本，值是对应的结果集。这个内存区域由参数query_cache_size控制大小，典型配置从几十MB到几百MB不等。
# 2. 查询缓存的工作流程 一个完整的查询缓存工作流程包括缓存检查、缓存存储和缓存失效三个主要环节：
缓存检查过程：
接收到SELECT查询后，MySQL首先对SQL文本进行规范化处理 计算规范化SQL的哈希值 检查哈希表中是否存在匹配项 如匹配成功，验证用户权限是否依然有效 权限验证通过后，直接从缓存返回结果集 缓存存储过程：
如果缓存未命中，查询将正常执行 执行完成后，检查查询是否可缓存（某些函数、视图等不可缓存） 如可缓存，将SQL文本和结果集存入查询缓存 建立查询与相关表的映射关系，用于后续失效处理 缓存失效机制：
当表数据发生变化时（INSERT、UPDATE、DELETE、ALTER等操作） MySQL自动使与该表关联的所有缓存项失效 失效操作是以表为粒度，而不是以具体行或查询为粒度 [插图2：查询缓存的工作流程示意图]
缓存检查是一个高效过程，但缓存失效机制却相对粗糙，这成为Query Cache性能问题的主要来源。
# 3. 查询缓存的关键特性 Query Cache有几个关键特性决定了其使用场景和限制：
精确匹配要求：
缓存匹配基于SQL文本的完全相同，包括大小写、空格和注释 即使语义相同但文本不同的查询会被视为不同查询 -- 这两个查询在缓存中被视为不同查询
SELECT * FROM users WHERE id = 1;
SELECT * from users where id = 1;
123 表级别的失效粒度：
任何对表的修改都会导致与该表相关的所有缓存失效 即使修改的数据与缓存的查询无关，缓存也会失效 在频繁写入的表上，缓存效果极差 全局锁设计：
缓存系统使用全局锁保护其数据结构 高并发下，这种设计导致严重的锁竞争 在多核服务器上，性能问题更为明显 内存管理机制：
使用FIFO（先进先出）算法管理缓存空间 频繁进行内存碎片整理，消耗CPU资源 大结果集可能导致缓存抖动，反而降低整体性能 [插图3：查询缓存的特性与限制示意图]
这些特性使得Query Cache在某些特定场景下表现良好（如读多写少、查询模式固定的应用），但在大多数现代应用场景中效果不佳。
# 4. 查询缓存的配置与监控 在MySQL 5.7及之前版本，查询缓存通过多个系统变量进行控制：
-- 查询缓存的工作模式
-- 0: 禁用, 1: 仅缓存select sql_cache的查询, 2: 缓存所有可缓存的查询
SHOW VARIABLES LIKE 'query_cache_type';
-- 查询缓存的大小（字节）
SHOW VARIABLES LIKE 'query_cache_size';
-- 能够缓存的单个结果集最大大小
SHOW VARIABLES LIKE 'query_cache_limit';
-- 最小的查询缓存块大小
SHOW VARIABLES LIKE 'query_cache_min_res_unit';
123456789101112查询缓存的性能可以通过以下状态变量监控：
-- 查看查询缓存的运行状态
SHOW STATUS LIKE 'Qcache%';
12关键监控指标包括：
Qcache_hits：缓存命中次数 Qcache_inserts：添加到缓存的查询数 Qcache_lowmem_prunes：由于内存不足从缓存中删除的查询数 Qcache_free_blocks：缓存中的空闲内存块数量（反映碎片化程度） 缓存命中率计算公式：
命中率 = Qcache_hits / (Qcache_hits + Com_select)
1一个健康的查询缓存通常应有较高的命中率（>30%）和较低的碎片化。
# 5. 查询缓存的问题与移除原因 尽管Query Cache在某些场景下能提供性能优势，但其设计存在多个根本性问题，最终导致在MySQL 8.0中被移除：
扩展性问题：
全局锁设计导致在高并发环境下性能急剧下降 每次缓存操作都需要获取互斥锁，成为瓶颈 多核服务器上，这种锁竞争问题更加严重 粗粒度失效机制：
表级别的缓存失效设计过于粗糙 在有写操作的表上，缓存效率极低 现代应用通常是读写混合模式，不适合此设计 内存管理效率低下：
频繁的内存碎片整理消耗资源 FIFO淘汰算法不够智能，无法识别热点查询 大结果集可能导致有用缓存被淘汰 代码维护难度高：
与MySQL其他模块紧密耦合，修改困难 代码复杂度高，bug修复和功能改进成本大 随着MySQL其他组件的发展，维护成本越来越高 [插图4：查询缓存设计缺陷示意图]
MySQL团队在多个版本中尝试改进Query Cache，但效果有限。最终在8.0版本中决定彻底移除这一功能，建议用户转向其他更高效的缓存解决方案。
# 6. 替代方案与最佳实践 随着Query Cache的移除，以下替代方案成为主流：
应用层缓存：
使用Redis、Memcached等专门的缓存系统 支持更细粒度的缓存控制和更智能的失效策略 可以跨多个数据库服务器共享缓存 数据库代理层缓存：
ProxySQL等数据库代理支持更智能的查询缓存 可以基于规则配置哪些查询可缓存 失效机制更灵活，支持基于时间的自动失效 MySQL内部优化：
InnoDB buffer pool已能缓存热点数据页 优化器缓存执行计划 表统计信息缓存 预编译语句减少解析开销 SQL优化与架构设计：
合理设计索引减少查询开销 读写分离分担主库压力 适当反范式化减少关联查询 [插图5：查询缓存替代方案对比]