针对原生MySQL Query Cache的不足，阿里云进行重新设计和全新实现，推出Fast Query Cache，能够有效提高数据库查询性能。
前提条件
- 实例版本为MySQL 5.7（内核小版本20200331或以上）。
- 实例未开启数据库独享代理。
背景信息
查询缓存（Query Cache）是为了提高查询性能而实现的一种缓存策略，其基本思想是：对于每个符合条件的查询语句，直接对结果集进行缓存，当下次查询命中时，直接从缓存中取出对应的结果集返回，不需要经历SQL的分析、优化、执行等复杂过程，通过节约CPU资源来达到查询加速的目标，是一项非常实用的技术。
MySQL原生Query Cache在设计和实现上存在着较多严重问题：
- 并发处理较差，在多核情况下，可能并发越高性能降低越严重。
- 内存管理较差，内存利用率低并且回收不及时，造成内存浪费。
- 当缓存命中率较低时，性能无提升甚至会出现严重降低。
由于以上问题，MySQL原生Query Cache没有得到广泛应用，在最新版的MySQL 8.0中，取消此功能。阿里云数据库团队对Query Cache进行重新设计和全新实现，解决了以上几个主要问题：
- 优化并发控制
取消全局锁同步机制，采用无锁机制，重新设计并发场景下的同步问题，能够充分利用多核的处理能力，保证高并发场景下的性能。
- 优化内存管理
取消内存预分配机制，采用更加灵活的动态内存分配机制，及时回收无效的内存，保证内存的真实利用率。
- 优化缓存机制
动态检测缓存利用率，实时调整缓存策略，解决命中率偏低或读写混合等场景下的性能降低问题。
相比原生Query Cache，Fast Query Cache可以在不同的业务场景中放心开启，提高查询性能。
使用Fast Query Cache
您可以在RDS控制台设置参数query_cache_type和query_cache_size使用Fast Query Cache。
| 参数 | 说明 |
|---|---|
| query_cache_type | Fast Query Cache功能开关，取值：
|
| query_cache_size | Fast Query Cache使用的内存大小，取值范围：0~10485760000，需要为1024的整数倍。单位：Byte。 |
由于Fast Query Cache功能需要占用额外的内存空间，所以建议使用Fast Query Cache功能时同步修改参数innodb_buffer_pool_size的大小，推荐的修改步骤如下：
- 修改innodb_buffer_pool_size为原先的90%，分出10%的空间给query_cache_size。例如原先为{DBInstanceClassMemory*7/10}，需要改为{DBInstanceClassMemory*63/100}。具体操作，请参见调整实例Buffer Pool大小。
- 修改参数query_cache_size。具体操作，请参见设置实例参数。
- 若能够评估结果集大小，query_cache_size可以设置为
20% * 结果集大小。 - 若无法准确评估结果集大小，query_cache_size可以设置为
10% * innodb_buffer_pool_size。
说明 如果变更实例规格，参数query_cache_size的值不会随实例规格变化，请及时修改此参数值。 - 若能够评估结果集大小，query_cache_size可以设置为
- 修改参数query_cache_type为1，开启Fast Query Cache功能。具体操作，请参见设置实例参数。
性能比较
在相同场景下，分别测试QC-OFF（关闭Query Cache）、MySQL-QC（开启MySQL原生Query Cache）和Fast-QC（开启Fast Query Cache）的QPS。
- 测试环境：4核8GB 独享型实例
- 测试工具：Sysbench
- 数据量：250MB（25张表，每张表40000条记录）
- 场景1：全部命中（只读）
测试场景为Sysbench oltp_point_select，用例中仅包括主键上的点查（point select），将Query Cache设为512MB，内存大于测试数据量，缓存可以全部命中，主要关注不同并发下的性能提升效果。
表 1. 全部命中（只读）QPS 并发数 QC-OFF MySQL-QC（相比QC-OFF提升） Fast-QC（相比QC-OFF提升） 1 8093 8771（8.38%） 9261（14.43%） 8 62262 65686（5.50%） 75313（20.96%） 16 97083 73027（-24.78%） 139323（43.51%） 32 97337 60567（-37.78%） 200978（106.48%） 64 106283 60216（-43.34%） 221659（108.56%） 128 107781 62844（-41.69%） 231409（114.70%） 256 106694 63832（-40.17%） 222187（108.25%） 512 101733 64866（-36.24%） 203789（100.32%） 1024 89548 62291（-30.44%） 203542（127.30%） 
说明 测试结果显示，在较高并发的场景下，MySQL原生Query Cache并发处理性能出现较大幅度的降低，Fast Query Cache在各个并发场景下无性能降低，最高时能够提高一倍的QPS。 - 场景2：高命中率（只读）
测试场景为Sysbench oltp_read_only，用例中包含返回多条记录的范围查询，将Query Cache设为512MB，内存才相对比较充足，命中率可以达到80%以上，这时主要关注不同并发下的性能提升效果。
表 2. 高命中率（只读）QPS 并发数 QC-OFF MySQL-QC（相比QC-OFF提升） Fast-QC（相比QC-OFF提升） 1 5099 6467（26.83%） 7022（37.71%） 8 28782 28651（-0.46%） 45017（56.41%） 16 35333 31099（-11.98%） 66770（88.97%） 32 34864 27610（-20.81%） 67623（93.96%） 64 35503 27518（-22.49%） 75981（114.01%） 128 35744 27733（-22.41%） 80396（124.92%） 256 35685 27738（-22.27%） 80925（126.78%） 512 35308 27398（-22.40%） 79323（124.66%） 1024 34044 26861（-22.10%） 75742（122.48%） 
说明 测试结果显示，随着并发数的增加，MySQL原生Query Cache的性能出现明显的降低，Fast Query Cache的性能则会不断提升，最高时能够提高一倍多的QPS。 - 场景3：低命中率（只读）
测试场景为Sysbench oltp_read_only，用例中包含返回多条记录的范围查询，将Query Cache设为16MB，内存明显严重不足，缓存命中率只有10%左右，内存不足时会涉及缓存项的大量淘汰，影响性能，这时主要关注不同并发下的性能降低程度。
表 3. 低命中率（只读）QPS 并发数 QC-OFF MySQL-QC（相比QC-OFF提升） Fast-QC（相比QC-OFF提升） 1 5004 4727（-5.54%） 5199（3.90%） 8 28795 22542（-21.72%） 28578（-0.75%） 16 35455 24064（-32.13%） 35682（0.64%） 32 34526 21330（-38.22%） 35871（3.90%） 64 35514 19791（-44.27%） 36051（1.51%） 128 35983 19519（-45.75%） 36253（0.75%） 256 35695 19168（-46.30%） 36337（1.80%） 512 35182 18420（-47.64%） 35972（2.25%） 1024 33915 20168（-40.53%） 34546（1.86%） 
说明 测试结果显示，MySQL原生Query Cache的性能降低明显，最多出现了接近50%的性能损失，Fast Query Cache优化了低命中率场景，几乎不会带来任何额外的性能损失。 - 场景4：读写混合
测试场景为Sysbench oltp_read_write，每个事务中都有对表的更新操作，可以认为缓存基本处于失效状态，频繁的更新操作涉及缓存的主动淘汰，理论上会比较影响性能，这时主要关注不同并发下的性能衰减程度。
表 4. 读写混合QPS 并发数 QC-OFF Fast-QC（相比QC-OFF提升） 1 4152 4098（-1.30%） 8 21359 21195（-0.77%） 16 26020 25548（-1.81%） 32 27595 26996（-2.17%） 64 29229 28733（-1.70%） 128 29265 28828（-1.49%） 256 29911 29616（-0.99%） 512 29148 28816（-1.14%） 1024 29204 28824（-1.30%） 
说明 测试结果显示，Fast Query Cache在读写混合场景下不会出现过多的性能降低，整体性能影响很小。
实践指南
在缓存数据集大小明确的情况下，例如使用SQL_CACHE关键字对指定表开启Query Cache，可以参照前面的测试进行性能评估。接下来将对Fast Query Cache的使用作一些补充说明。
- 适用场景指南
- Fast Query Cache主要目的是提高读操作性能，建议在读多写少的场景下开启，或者使用SQL_CACHE关键字针对读多写少的表开启。如果写多读少，数据的更新非常频繁，可能会出现很少的性能降低。
- 开启Fast Query Cache带来的性能提升和缓存命中率直接相关。在全局开启前建议查看InnoDB Buffer Pool的命中率（命中率 = 1 - Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests），如果命中率低于80%，则不建议开启。您也可以通过TABLE_STATISTICS表查看表级别的读写比，对读写比高的表通过SQL_CACHE关键字显式开启Fast Query Cache。查询TABLE_STATISTICS表请参见Performance Insight。
- 缓存使用方式（query_cache_type）
query_cache_type参数支持会话级修改，用户可以根据真实业务场景进行灵活设置，请参见以下建议：
- 对于更新频繁、写多读少等不适合Query Cache的场景，应将query_cache_type全局设置为0。
- 对于数据量较小、访问模式比较固定、命中率较高的场景，可以将query_cache_type全局设置为1。
- 对于数据量较大、访问模式不固定、命中率无法保障的场景，可将query_cache_type设置为2，仅对指定的语句，通过SQL_CACHE关键字使用Fast Query Cache。
- 缓存大小（query_cache_size）设置
query_cache_size和SQL息息相关，如果缓存中有返回多条记录的查询，缓存可能需要是数据量的数倍。如果SQL中不包含范围查询，可以参见以下测试来评估数据量和query_cache_size的关系。
- 测试环境：4核8GB独享型实例（innodb_buffer_pool_size=6GB）
- 测试工具：Sysbench
- 数据量：10GB（100张表，每张表400000条记录）
测试场景为Sysbench oltp_point_select、64并发、Special分布（20%热点）。测试不同query_cache_size大小对于性能的影响。对应上述的数据量，全量结果集的真实大小为2.5GB。
表 5. 不同缓存QPS query_cache_size（MB） QC-OFF Fast-QC命中率 Fast-QC（相比QC-OFF提升） 64 98236 22% 99440（1.23%） 128 98236 45% 114155（16.21%） 256 98236 72% 140668（43.19%） 512 98236 82% 151260（53.98%） 1024 98236 84% 153866（56.63%） 2048 98236 87% 159597（62.46%） 4096 98236 92% 169412（72.45%） Fast Query Cache在不同query_cache_size的设置下都不会引起性能退化，对于主键查询操作，在不同缓存命中率下都有性能提升，达到90%以上时，提升效果比较明显；对于范围查询或带
Order By的排序语句，缓存命中率低于90%时，也能节约大量的CPU，带来较大的性能提升。