MySQL 查询缓存内存管理机制与失效规则详解

查询缓存的性能权衡

启用查询缓存虽能提升重复查询效率，但同时也引入了额外的系统开销：

• 读取开销：在执行实际查询前，服务器必须检查查询缓存是否存在匹配项。
• 写入开销：当生成新的查询结果后，需将其序列化并保存到缓存中，这增加了 CPU 和 I/O 负担。
• 维护开销：缓存块的分配、紧缩以及因数据更新导致的缓存失效清理都需要消耗资源。

内存分配与内存池机制

MySQL 查询缓存的内存管理基于一个可变大小的块（block）结构。每个块不仅记录自身大小，还通过指针链接到前驱和后继的逻辑块及物理块，形成双向链表以便快速检索可用空间。

第1步：初始化内存池

服务器启动时，根据配置初始化查询缓存的物理内存。内存池最初包含一个大块，其大小为配置的总缓存大小减去约 40KB 的管理开销。这部分内存用于后续的动态分配。

第2步：动态分配与流式写入

由于服务器难以预先准确估计查询结果的大小，直接一次性分配可能面临空间不足或内存浪费的风险。因此，MySQL 采用以下策略：

1. 最小单位约束：每次分配的块大小至少为 query_cache_min_res_unit（默认值为 4096 字节，即 4KB）。该参数定义了分配给查询缓存的最小内存块大小。
2. 分块构建：服务器不会在内存中拼凑好完整结果集后再写入，而是产生一条缓存一条。首先分配一个不小于最小单位的块存放部分数据。
3. 动态扩展：如果当前块已满但结果尚未生成完毕，系统会分配一个新块继续存储数据。

这种机制虽然保证了空间利用率，但由于需要频繁查找合适的空闲块并插入链表，分配速度相对较慢。为此，服务器尽量减少分配次数，并通过“紧缩”操作优化内存：

• 紧缩（Compaction）：当数据保存完成后，如果最后一个使用的数据块存在剩余空隙，服务器会将该空隙合并到剩余的空闲空间中，从而减少内存碎片，提高后续大结果集的分配成功率。

查询缓存失效与不被缓存的场景

尽管缓存能加速读操作，但在某些特定情况下，即使使用 SQL_CACHE 提示，查询结果也不会被缓存。这些情况主要包括：

• 引用用户自定义函数（UDF）：由于 UDF 的行为可能具有不确定性或外部依赖性。
• 引用用户自定义变量：变量的值依赖于会话状态，无法保证多次执行的一致性。
• 使用存储过程：存储过程的复杂性可能导致输出结果非确定性。
• 包含实时系统函数：如 NOW()、CURDATE() 等，其返回值随时间变化，缓存旧结果会导致数据错误。
• 引用临时表：临时表的数据通常具有会话特异性或短暂性。

事务对缓存的影响（InnoDB 引擎）

对于使用 InnoDB 等事务存储引擎的场景，缓存行为受到事务状态的严格约束：

1. 脏数据保护：如果一个查询涉及的数据在当前有未提交的事务正在修改（即存在脏数据），这些数据相关的缓存条目必须保持失效或不被缓存，以确保隔离性。
2. 一致性判断：只有当事务成功 提交（COMMIT） 或 回滚（ROLLBACK） 后，该事务影响的数据范围才会被视为稳定，此时相关的缓存条目才可能被安全地更新或保留。

这一机制确保了在高并发事务环境下，数据库读取的一致性与缓存命中率之间的平衡。

关键参数说明

• query_cache_type：控制缓存的全局开关模式（ON/OFF/DEMAND）。
• query_cache_min_res_unit：最小分配块大小，默认为 4KB。调整此值可以优化小结果集和大结果集的性能表现，但需谨慎测试以避免过度碎片化。

以上就是 MySQL 查询缓存内存管理及失效规则的详细内容，更多关于 MySQL 性能优化的资料请关注本站其它相关文章！