针对原生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_typequery_cache_size使用Fast Query Cache。

参数 说明
query_cache_type Fast Query Cache功能开关,取值:
  • 0:默认值,禁用Fast Query Cache。
  • 1:使用Fast Query Cache,但可通过SQL_NO_CACHE关键字跳过缓存。
  • 2:不启用Fast Query Cache,但可通过SQL_CACHE关键字对特定语句使用缓存。
query_cache_size Fast Query Cache使用的内存大小,取值范围:0~10485760000,需要为1024的整数倍。单位:Byte。

由于Fast Query Cache功能需要占用额外的内存空间,所以建议使用Fast Query Cache功能时同步修改参数innodb_buffer_pool_size的大小,推荐的修改步骤如下:

  1. 修改innodb_buffer_pool_size为原先的90%,分出10%的空间给query_cache_size。例如原先为{DBInstanceClassMemory*7/10},需要改为{DBInstanceClassMemory*63/100}。具体操作,请参见RDS MySQL内存管理
  2. 修改参数query_cache_size。具体操作,请参见设置实例参数
    • 若能够评估结果集大小,query_cache_size可以设置为20% * 结果集大小
    • 若无法准确评估结果集大小,query_cache_size可以设置为10% * innodb_buffer_pool_size
    说明 如果变更实例规格,参数query_cache_size的值不会随实例规格变化,请及时修改此参数值。
  3. 修改参数query_cache_type1,开启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,带来较大的性能提升。