为什么mysql8要取消查询缓存？

为什么mysql8要取消查询缓存？

在数据库领域，查询缓存是提升性能的关键技术之一。社区MySQL版本在2001年引入Query Cache功能，旨在缓存查询结果，以减少重复查询的计算开销。然而，随着时间的推移，Query Cache在并发支持、内存管理、场景支持等方面暴露出了诸多问题，导致其使用率逐渐下降，最终在MySQL 8.0版本中被移除。为解决这些问题，PolarDB MySQL在2020年推出了Fast Query Cache，旨在提供更高效的查询缓存解决方案。

对比社区Query Cache，Fast Query Cache进行了全方位的技术革新。首先，Fast Query Cache设计中完全摒弃了全局锁机制，通过无锁HASH结构管理查询缓存节点和表的映射，大大提高了并发处理能力。在Fast Query Cache中，引用相同表的查询不再使用链表链接，而是通过表的版本号和引用计数来管理缓存，使得DML、DDL等导致缓存失效的操作更加高效，不会被查询命中阻塞。

在内存管理方面，Fast Query Cache采用了动态内存分配策略，只在生成新的缓存时向内存分配器申请空间，同时通过后台线程回收失效的缓存，避免了内存的浪费和资源占用。此外，Fast Query Cache还引入了LRU链表机制，新写入或命中的缓存会自动调整到链表尾部，当内存使用率高时，系统会自动淘汰最老的未命中缓存，实现高效内存管理。

Fast Query Cache在集群支持方面也进行了优化，通过多节点集群架构，主节点和只读节点之间的事务提交信息被用于失效管理，确保只读节点不会读取已失效的数据。同时，Fast Query Cache支持session tracker，能够动态生成OK报文，避免了社区版本中存在的追踪信息错误问题。

在结果正确性保证上，Fast Query Cache采用了更准确的事务提交版本号来判断缓存可见性，而不是仅通过trx_id。这有效解决了社区版本中Repeatable-read隔离级别下的缓存正确性问题。此外，Fast Query Cache在只读节点上不支持Read-Uncommitted隔离级别。

Fast Query Cache还引入了自适应缓存控制模块，能够根据系统负载和缓存使用情况动态调整缓存策略，以避免对系统性能的负面影响。在高并发场景下，Fast Query Cache可以将系统吞吐量的影响控制在3%以内，同时对于频繁更新的表，Fast Query Cache会避免缓存写入，以减少无效的缓存与失效开销。

在业务场景选择上，Fast Query Cache适合各种数据批量导入和分析的场景，如营销系统、教育行业、订单系统等。这些场景中，数据量大但更新频率不高，存在重复访问的需求，Fast Query Cache能够显著提升查询性能。

配置Fast Query Cache涉及的变量包括query_cache_type（开启功能）、query_cache_size（内存使用量）、query_cache_limit（最大缓存结果集大小）和query_cache_lease_time（缓存未命中后失效时间）。同时，Fast Query Cache支持的查询类型仅限于SELECT语句，存在一些使用限制，例如不支持DML、DDL操作的缓存。

综上所述，PolarDB Fast Query Cache通过优化并发处理、内存管理和自适应策略，提供了更高效、更灵活的查询缓存解决方案，适用于各种业务场景，有效提升了数据库性能，减轻了系统负载，为企业提供了更稳定、更高效的数据库服务。2024-11-02