摘要：查询缓存（QC）像一把双刃剑。在读多写少、重复查询多的场景中，QC能显著提升性能。然而，在写多读少的场景中，QC不仅消耗内存资源，还会因为查询缓存和缓存命中判断等额外步骤导致性能下降。
摘要：查询缓存（QC）像一把双刃剑。在读多写少、重复查询多的场景中，QC能显著提升性能。然而，在写多读少的场景中，QC不仅消耗内存资源，还会因为查询缓存和缓存命中判断等额外步骤导致性能下降。
本文分享自华为云社区《【华为云MySQL技术专栏】MySQL Query Cache使用与实现-云社区-华为云》，作者：GaussDB 数据库。
查询缓存（Query cache，简称QC）是一种数据库优化技术，用于存储查询结果，以便在相同查询再次执行时能够快速返回结果，而无需重新执行查询。MySQL也有QC对应实现，但因其实现存在并发性能差、缓存命中率低等问题，该特性在MySQL 5.7.20标记为不推荐使用，在MySQL 8.0.3里被删除。
QC对于特定场景可以显著提升性能，TaurusDB保留QC并对其并发性能进行了优化。本文基于MySQL 8.0.2代码对QC的使用与实现进行分享，介绍TaurusDB如何进行优化。
在使用QC特性后，MySQL服务端会缓存符合条件（见文末链接）的查询与查询结果。
接收查询后，不会立刻解析和执行，而是优先从QC中检索结果返回。
QC是全局的，不同session可以共享QC功能，更详细介绍参考文末官网链接。
图1 QC缓存、命中流程图
QC相关系统参数相关参数都包含query_cache关键字，用如下SQL查询。
mysql> show variables like '%query_cache%';表1 QC系统参数说明
QC功能开启前提query_cache_type!=off且query_cache_size!=0，具体参数使用见官网说明。
QC相关统计参数相关参数都包含Qcache关键字，用如下SQL查询。
表2 QC统计参数说明
QC底层是一个内存池，所以包含内存池状态参数。上述参数反应当前QC的使用状态，以供使用者调整优化。如：
（1）Qcache_hits/(Qcache_hits+Qcache_inserts)可视作缓存命中率，过低说明QC功能对当前业务作用不大，可考虑关闭QC。
（2）Qcache_free_block/Qcache_total_block可视作缓存碎片率，过高可使用flush query cache进行碎片整理或根据业务适当减小query_cache_min_res_unit。
图2 内存池状态（1）
第二种，查询命中，从 QC 中直接返回查询结果。
图3 内存池状态（2）
第三种，查询失效。发生影响缓存结果正确性的操作时（如相关表DDL、DML），对应缓存失效。
图4 内存池状态（3）
QC的业务实现和内存池有着密切的关系。为了更好理解QC实现，后文将从内存池设计和QC业务实现两方面进行介绍。需要注意，两者在代码层面不是割离的，都在一个全局对象Query_cache中实现。在设计层面，内存池的方案选择也会受到QC业务影响。
内存池的实现，会先申请一整块连续内存，但在处理申请、释放内存的请求后，整块内存逐渐会被分割为多个内存块（block）。根据内存块是否正在使用，可分为空闲内存块（free block）与非空闲内存块（used block）。
图5 内存池变化图
通过图5可以发现，内存池核心接口是内存的申请与释放，并且在内存池使用过程中会出现内存碎片化问题。
那么申请内存时，如何找到内存池中不小于所需大小的空闲块？如何知道各内存块的大小和空闲状态？如果有多个合适的空闲块，如何选择？如果选中的空闲块比申请的大，多余的空间（内部碎片）怎么处理？释放内存时，又该如何处理释放的内存块？
下面将分析QC如何解决上述问题，同时缓解内存的碎片化。
图6 内存块抽象图
如图6所示，QC内存池将内存块大小、类型等元信息存储在块头部。用数组（bins）根据块大小对空闲内存块进行管理。
class Query_cache {Query_cache_memory_bin *bins;};// 一个bin元素维护一条空闲内存块链表，链表有如下特征（设当前数组下标为i）：// 1、链表管理块大小范围在bins[i].size ~ bins[i-1].size之间；// 2、链表中空闲内存块从小到大有序；// 3、链表为双向链表，并且头尾相连。struct Query_cache_memory_bin {Query_cache_block *free_blocks; // 空闲内存块链表ulong size; // 链表管理块大小范围下限，最小为512Buint number; // 当前链表长度 };数组长度与成员赋值根据内存池大小经过内部算法确定，算法有如下特征：
图7 free block管理
（1）数组成员下标越小管理的空闲内存块大小越大。如图7左边所示，bins[0]管理空闲内存块大小大于bin[1]管理的。
（2）数组成员下标越大管理的空闲内存块大小范围越小。如图7左边所示，bins[1]管理空闲内存块是5-8M，范围是3M，而bins[3]管理空闲内存块是1-2M，范围是1M）。
考虑到小对象往往会分配更频繁，越可能是性能瓶颈，所以算法会生成更多bin元素对小内存块进行更加细致的管理。
设当前内存池大小为128M，经过一段时间运行后，如图7右边所示（链表首尾相连，图中未画）。
若申请大小为6M，当前有多个内存块符合申请大小。如图8所示，通常有如下选择策略：
图8 内存池物理、逻辑结构
第一种策略，first fit。
在物理上进行遍历，返回第一个不小于申请大小free block（10M）。此策略寻找空闲内存块时间比较短，但块大小可能超出6M较多，易造成内存碎片。
第二种策略，best fit。
best fit返回最小不小于申请大小free block，可利用bins数组查找：
（1）根据申请大小找到对应的bin元素（6M对应bins[1]）。
（2）遍历bin中free block链表，因链表有序，返回第一个不小于申请大小的块（8M）。
初看best fit是一个不错的方案，但如果free block链表长度过长，时间会线性增加。因此，QC在best fit基础上进行优化，将第二步的链表遍历修改为：从链表头向后（从小到大）遍历最多5次，若找到符合要求内存块返回，否则从链表尾向前（从大到小）遍历最多5次，返回这五个内存块中最小符合要求的内存块。
若申请8M内存块，但写入数据只有6M，则会出现了2M的内部碎片，如图9所示。若不处理，将影响内存利用率。
图9 内部碎片处理
QC的处理方式：如果内部碎片不大于512B不进行处理，否则将内部碎片从内存块中分离，视作新增的free block纳入bins中管理。
内存释放除了需要重置内存块后纳入对应bin管理，还需合并相邻的空闲内存块，以减少内存碎片。
图10 内存释放处理
如图10中所示，若释放内存块大小为7M，物理相邻内存块也是空闲，从左到右即为内存池的变化过程。
关键数据结构
关键数据结构就是前文常提的抽象概念内存块，对应代码中的Query_cache_block。
struct Query_cache_block {block_type type; // 块类型，主要可分为query\table\result blockulong length, used; // 块大小、块已使用大小Query_cache_block *pnext,*pprev, // 块物理前后指针 *next,*prev; // 块逻辑前后指针，不同块类型有不同使用方式int n_tables; // 块中Query_cache_block_table数组个数// 获取第n个Query_cache_block_tableinline Query_cache_block_table *table(TABLE_COUNTER_TYPE n); inline uchar* data; // 获取块的data起始地址inline Query_cache_query *query; // 将data以query block方式解析inline Query_cache_table *table;// 将data以table block方式解析inline Query_cache_result *result;// 将data以result block方式解析};图11 block内存结构
图11中，元信息中Query_cache_block_table数组，作用是维护block之间关联关系，具体用法后文分析。
根据data存储内容不同，block主要被分为三种类型query,table,result block。
我们用一个简单SQL的执行作为例子，如查询：select * from t1 join t2 where t1.a = t2.a，来探究一个查询在内存池中对应哪些block。
query block图12 query block结构图
图12中，一个查询对应一个query block，data记录查询SQL与查询状态（影响输出参数）。
query block中有t1、t2的Query_cache_block_table链表节点，与t1、t2的table block关联（table block中解释关联作用）。
Query_cache_query记录元信息，如查询对应的result block指针。
table block图13 table,query block关系图
图13中，一张表对应一个table block，data记录数据库名和表名。
table block有Query_cache_block_table链表头节点与相关的query block相连，方便后续通过库表名找到相关query block。
result block图14 查询结果写入流程图
图14中，result block的data记录MySQL返回客户端的packet内容.
因为packet的发送可能分为多次，所以result block在初次申请内存时，无法确定最终大小，这会导致一个查询可能对应的多个result block的情况，同一个查询的result block之间使用指针维护一个链表。
当查询一对应2个result block时，table,query,result block之间对应的关系图如图15所示。
图15 table，query，result block关系图
图16 QC流程图
缓存查询实现对应图16中，若QC未命中分支，主要有2个步骤：
步骤一，QC存储查询内容。
通过调用Query_cache::store_query，创建query,table block，并维护对应的哈希表和链表。
步骤二，QC存储查询结果。
通过调用query_cache_insert，基于MySQL向客户端返回的packet内容生成result block，可参考查询结果写入流程图（图14）。
缓存命中实现对应图16中，若QC命中分支，主要有1个步骤，即QC命中判断：在解析前调用Query_cache::send_result_to_client，使用query block哈希表来判断查询是否命中。若命中则直接调用函数net_write_packet，对客户端发送缓存结果。
缓存失效实现缓存失效场景，相关表发生ddl、dml、内存池不足导致缓存失效等。参考图15（table,,query,result block关系图），dml的缓存失效流程如下：
（1）通过库表名在table block的哈希表中找到table block；
（2） 通过table block中Query_cache_block_table链表头找到与此表相关query block；
（3）根据query block的result block指针，找到对应的result block；
（4）对上述block进行释放。
内存池整理命令QC提供了命令FLUSH QUERY CACHE，可手动触发内存池空间整理。分为两个步骤：
第一，pack cache，将free block移动到内存池底部。
第二，join result，将属于同一查询的多个result block（result1.1，result1.2）进行合并，此操作将导致内存碎片重新出现，需再进行一次pack cache。
图17 内存池空间整理
如图17所示，整理后内存池只有1个free block，也对result block进行了整合。
并发处理为了应对MySQL的并发查询，QC内存池需设计并发策略来保证QC业务的正确性。
QC锁
要求所有对内存池的操作（插入、删除、查询）需提前持有QC锁。其实质是将并发操作序列化，以保证正确性；
查询结果写入持锁优化
根据图14（查询结果写入流程图），对查询结果写入的持锁范围进行了优化——不需全程持锁，在进行result block写入时持锁即可。
图18 写入流程优化
写入流程不需全程持锁，只需对内存池真正操作的 Query_cache::insert函数中持锁即可。但此优化引入一个新问题：如果同时有两个会话进行相同的查询，可能会导致两个线程对查询结果共同写入的情况，造成缓存结果错误。
此优化引入一个新问题：同时有两个会话进行相同查询，造成两个线程对同一查询结果同时写入的情况，造成缓存结果错误。
解决方案：
在query block中新增成员变量writer，创建query block时，writer记录线程号，后续result block只能由该线程写入。这样就可以确保每个查询结果，只能由一个线程写入，从而避免缓存结果的错误。
事务场景1）多语句事务:
单语句事务和多语句事务中，相同查询对应不同的缓存。
-- 查询1进行缓存select * from t1;begin;-- 查询2进行缓存select * from t1;2）行锁写锁:
表有行写锁时，不会进行缓存。
begin;insert into t1 values(1);-- 不会缓存select * from t1;3）RC场景:
DML、DDL操作会对相关查询缓存失效，所以,QC中查询缓存都是最新提交的结果，符合读已提交的定义，RC可以正常使用QC特性。
4）RR场景:
为了适配RR隔离级别，在表元数据中新增变量（query_cache_inv_id）记录对表的最新操作的事务ID(trx_id)。如果RR事务.trx_id
-- session 1begin;select * from t2; //开启事务1，设trx_id=1-- session 2insert into t1 values(1); //t1的query_cache_inv_id设置为当前trx_id（2）begin;select * from t1; //缓存查询-- session 1select * from t1; //事务1.trx_id本章对内存池设计和QC业务设计的原理进行了分析，并总结了各自的优缺点。
内存池设计优点：
1. 利用数组（bins）、链表结构，以内存块大小管理空闲内存，申请内存高效；
2. 内部碎片及时处理、释放内存时将物理相邻free block合并，自动优化内存池；
3. 提供FLUSH QUERY CACHE命令可手动触发整理内存池。
内存池设计缺点：
1.内存池大小无法动态调整，调整大小会重新初始化，丢失缓存数据；
2.不支持并发操作内存池，使用QC锁使操作序列化，高并发场景性能下降严重。
查询业务设计优点：
1. 将block分类，利用链表、哈希表等结构，简洁实现查询缓存、命中、失效等功能；
2. 查询结果可分在多个result block存储，提升内存利用率；
3. 查询结果写入流程中减少QC锁持有的时间，提升性能；
4. 适配数据库的事务场景，支持RC/RR隔离级别使用。
查询业务设计缺点：
缓存失效方式粗粒度，对表进行任何DML\DDL操作，相关QC都将失效。
如上文所示，社区MySQL实现QC内存池不支持并发操作。面对并发查询场景时，性能不仅没有得到优化，反而可能会下降。TaurusDB对此新增了参数query_cache_instances，如表3所示。
表3 query_cache_instantces参数说明
该参数可以指定QC内存池个数，将内存池一分为多。QC业务会根据查询的哈希值到指定的内存池进行对应操作，以此减少并发冲突。
为了评估`query_cache_instances` 参数对性能的影响，进行只读场景测试，测试query_cache_instantces参数（0、1、16、64）在不同并发数下QPS变化。
注：测试环境是笔者开发机，绝对值无参考意义，关注变化趋势。
图19 QC性能比较
可以看到，虽然优化原理简单，但是对性能提升是立竿见影的。
查询缓存（QC）像一把双刃剑。在读多写少、重复查询多的场景中，QC能显著提升性能。然而，在写多读少的场景中，QC不仅消耗内存资源，还会因为查询缓存和缓存命中判断等额外步骤导致性能下降。
总体来看，QC 是一个使用难度较高的特性。用户需要了解其工作原理，并根据自身业务特点，通过调整相关系统参数、统计参数和优化命令来进行监控与调整。
MySQL 社区版没有解决并发查询性能差的问题，而 TaurusDB 新增的 `query_cache_instances` 参数，则能够在高并发场景下提供更好的性能优化，使用户能够更充分地利用 QC 的优势。
MySQL QC官网介绍，https://dev.mysql.com/doc/refman/5.7/en/query-cache.html
MySQL服务端会缓存符合条件的查询与查询结果，https://dev.mysql.com/doc/refman/5.7/en/query-cache-operation.html
来源：Horry很忙
