当前位置：网站首页>华为云专家详解GaussDB(for MySQL)新特性

华为云专家详解GaussDB(for MySQL)新特性

2022-07-01 18:38:00 【InfoQ】

本文分享自华为云社区《

GaussDB创新特性解读：Partial Result Cache，通过缓存中间结果对算子进行加速

》，作者：GaussDB 数据库。

为了加速查询性能，传统的关系型数据库，比如Oracle、DB2，都有结果集缓存的特性，用来缓存一条查询语句的结果集。如果后续同样的语句被查询，数据库将直接从结果集缓存中获取结果，而不用再重新执行该查询。MySQL 在4.0版本中也引入了结果集缓存Query cache，但是在设计上有局限性，具体如下：

Query cache针对单个查询，任何一个表做了修改，如果影响到结果集就需要刷新或者失效。

Query cache对隔离级别有依赖，不同的隔离级别产生的结果集不一样。

Query cache需要对所有数据进行缓存，如果表结果比较大的话，缓存需要占据较大的内存或者写入磁盘。

这也导致了该特性在MySQL 8.0版本被移除。

鉴于结果集缓存对查询性能的增益，我们在GaussDB（for MySQL）引入

Partial result cache

这一新特性，简称PTRC。顾名思义，这也是一个结果集缓存特性。不同于传统的结果集缓存，PTRC是用来辅助单个查询的内部算子的执行。也就是说PTRC粒度更小，是对查询内部的某个算子的中间结果进行缓存，从而起到算子加速的作用。

这里的Partial 有两层概念：

从这两点可以看出，PTRC是与单个查询相关的，生命周期从查询开始到查询结束，自动终止。由于它是对算子进行加速，所以一个查询内部可以有多个PTRC。只要优化器根据代价计算，认为该算子适合PTRC，那么优化器就会为该算子引入PTRC。

PTRC如何确定对算子并加速？

这里我们引入一个新概念：

参数化的重复扫描

，指的是扫描算子根据参数的不同进行算子扫描。比如Nested Loop Join，对于外表扫描的每一条数据，内表会根据JOIN条件进行扫描，那么对于内表来说就是一次“参数化的重复扫描”。再比如相关子查询，对于父查询的每一次扫描都会根据父查询的结果集调用子查询执行，然后返回子查询的结果集。

PTRC是如何工作的？

如前所述，PTRC是缓存算子的中间结果集，那么也和其他cache一样，将数据以key ，value的方式缓存到cache中，通过key来命中，得到value。那么PTRC的相关key和value是如何获取的？

下面我们以Correlated subquery为例做简单分析，查询语句如下：

SELECT *

FROM t1

WHERE t1.a IN (SELECT a

 FROM t2,

 t3

 WHERE t2.b = t1.b

 AND t2. c > t3.d);

上图是子查询使用EXISTS策略执行的流程图。可以看出：对于数据表t1中的每一条数据，都会驱动子查询执行，直到数据表t1中的所有记录都循环结束。对于数据表t1中的每一条记录对应的t1.a，都需要根据该列值重新扫描子查询，进而判断子查询的返回值。

我们通过EXPLAIN来对比引入PTRC前后执行计划的差异：

EXPLAIN format=tree

SELECT *

FROM t1

WHERE t1.a IN (SELECT a

 FROM t2,

 t3

 WHERE t2.b = t1.b

 AND t2. c > t3.d);

-> Filter: <in_optimizer>(t1.a,<exists>(select #2)) (cost=0.35 rows=1)

-> Table scan on t1 (cost=0.35 rows=1)

-> Select #2 (subquery in condition; dependent)

-> Result cache : cache keys(t1.a, t1.b)

-> Limit: 1 row(s) (cost=0.80 rows=1)

-> Filter: (t2.c > t3.d) (cost=0.80 rows=1)

-> Inner hash join (no condition) (cost=0.80 rows=1)

-> Table scan on t3 (cost=0.35 rows=2)

-> Hash

-> Filter: ((t2.b = t1.b) and (<cache>(t1.a) = t2.a)) (cost=0.35 rows=1)

-> Table scan on t2 (cost=0.35 rows=1)

可以看出引入PTRC后，多了一个算子

Result cache（标红部分）

，表明该算子当前的子查询引入了PTRC，引入后的执行流程变更为：

引入PTRC后，对于数据表t1中的每一条数据对应的t1.a列值，优先查看PTRC，如果命中，直接从PTRC中获取结果集，而不需要执行子查询。如果未命中，需要按原来的方式继续执行子查询，子查询执行的结果会储存到PTRC中。如果下一次同样的列值来驱动执行子查询，可以直接从PTRC获取。

优化器如何选择PTRC？

优化器在为算子选择PTRC的时候会依赖

代价估算

，主要是看

命中率

（命中率 = 不同键值的行数/键值的总行数），如果命中率大于rds_partial_result_cache_cost_threshold（具体含义参考下文的系统变量介绍）变量定义的最小代价，PTRC将会被选择，反之则不会被选择。是否选择了PTRC，可以通过Explain format=tree或者Explain analyze来观察实际的命中情况。我们通过一个例子来说明：

EXPLAIN analyze

SELECT *

FROM t1

WHERE t1.a IN (SELECT a

 FROM t2,

 t3

 WHERE t2.b = t1.b

 AND t2. c > t3.d);

-> Filter: <in_optimizer>(t1.a,<exists>(select #2)) (cost=0.35 rows=1) (actual time=3800.595..3800.595 rows=0 loops=1)

-> Table scan on t1 (cost=0.35 rows=1) (actual time=0.064..0.093 rows=1 loops=1)

-> Select #2 (subquery in condition; dependent)

-> Result cache : cache keys(t1.a, t1.b) (Cache Hits: 0, Cache Misses：1, Cache Evictions: 0, Cache Overflows: 0, Memory Usage: 40960 ) (actual time=0.115..0.115 rows=0 loops=1)

-> Limit: 1 row(s) (cost=0.80 rows=1) (actual time=0.094..0.094 rows=0 loops=1)

-> Filter: (t2.c > t3.d) (cost=0.80 rows=1) (actual time=0.093..0.093 rows=0 loops=1)

-> Inner hash join (no condition) (cost=0.80 rows=1) (actual time=0.092..0.092 rows=0 loops=1)

-> Table scan on t3 (cost=0.35 rows=2) (never executed)

-> Hash

-> Filter: ((t2.b = t1.b) and (<cache>(t1.a) = t1.a)) (cost=0.35 rows=1) (actual time=0.039..0.039 rows=0 loops=1)

-> Table scan on t2 (cost=0.35 rows=1) (actual time=0.038..0.038 rows=0 loops=1)

从Result cache这个算子后面可以看到：

Cache Hits: 0，表示命中的次数为0

Cache Misses：1，表示没有命中的次数为1

Cache Evictions: 0，表示使用LRU淘汰的记录数

Cache Overflows: 0，表示内存overflow的次数

Memory Usage： 40960，表示当前查询使用的内存量

由于优化器使用代价估算来计算是否使用PTRC，如果估算错误的话，PTRC还是有额外的代价，比如创建自身的一些数据结构，以及记录的拷贝。为了尽可能的保证查询的性能，PTRC采取了

动态反馈

的方式来查看PTRC在实际执行的过程中是否继续使用。PTRC会自动判断命中率是否适合保留PTRC，优化器根据没有命中的次数，每隔rds_partial_result_cache_hit_ratio_frequency会检查命中率是否低于rds_partial_result_cache_min_hit_ratio。如果低于该值，优化器会自动禁止继续使用PTRC。

优化器如何限制PTRC的内存使用

由于单个查询可以有多个PTRC算子，每个算子都会使用内存来存储缓存数据，那么控制PTRC内存使用就非常有必要，以防止内存OOM。

通过系统变量rds_partial_result_cache_max_mem_size来定义每个查询所使用的所有PTRC算子使用的最大内存。如果PTRC使用的内存总数超过该值，优化器会根据LRU算法来进行淘汰。如果通过LRU算法可以找到适合当前存储记录的大小的记录进行淘汰，当前记录可以进行缓存，否则当前记录将不被缓存。