下推计算结果缓存

TiDB 从 4.0 起支持下推计算结果缓存（即 Coprocessor Cache 功能）。开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，在部分场景下起到加速效果。

配置

Coprocessor Cache 的配置均位于 TiDB 的 tikv-client.copr-cache 配置项中。Coprocessor 的具体开启和配置方法，见 TiDB 配置文件描述。

特性说明

• 所有 SQL 在单个 TiDB 实例上的首次执行都不会被缓存。

• 缓存仅存储在 TiDB 内存中，TiDB 重启后缓存会失效。

• 不同 TiDB 实例之间不共享缓存。

• 缓存的是下推计算结果，即使缓存命中，后续仍有 TiDB 计算。

• 缓存以 Region 为单位。对 Region 的写入会导致涉及该 Region 的缓存失效。基于此原因，该功能主要会对很少变更的数据有效果。

• 下推计算请求相同时，缓存会被命中。通常在以下场景下，下推计算的请求是相同或部分相同的：

  • SQL 语句完全一致，例如重复执行相同的 SQL 语句。

    该场景下所有下推计算的请求都是一致的，所有请求都能利用上下推计算缓存。

  • SQL 语句包含一个变化的条件，其他部分一致，变化的条件是表主键或分区主键。

    该场景下一部分下推计算的请求会与之前出现过的一致，部分请求能利用上下推计算结果缓存。

  • SQL 语句包含多个变化的条件，其他部分一致，变化的条件完全匹配一个复合索引列。

    该场景下一部分下推计算的请求会与之前出现过的一致，部分请求能利用上下推计算结果缓存。

• 该功能对用户透明，开启和关闭都不影响计算结果，仅影响 SQL 执行时间。

检验缓存效果

可以通过执行 EXPLAIN ANALYZE 或查看 Grafana 监控面板来检查 Coprocessor 的缓存效果。

使用 EXPLAIN ANALYZE

用户可以通过 EXPLAIN ANALYZE 语句查看读表算子中的缓存命中率，示例如下：

EXPLAIN ANALYZE SELECT * FROM t USE INDEX(a); +-------------------------------+-----------+---------+-----------+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+-----------------------+------+ | id | estRows | actRows | task | access object | execution info | operator info | memory | disk | +-------------------------------+-----------+---------+-----------+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+-----------------------+------+ | IndexLookUp_6 | 262400.00 | 262400 | root | | time:620.513742ms, loops:258, cop_task: {num: 4, max: 5.530817ms, min: 1.51829ms, avg: 2.70883ms, p95: 5.530817ms, max_proc_keys: 2480, p95_proc_keys: 2480, tot_proc: 1ms, tot_wait: 1ms, rpc_num: 4, rpc_time: 10.816328ms, copr_cache_hit_rate: 0.75} | | 6.685169219970703 MB | N/A | | ├─IndexFullScan_4(Build) | 262400.00 | 262400 | cop[tikv] | table:t, index:a(a, c) | proc max:93ms, min:1ms, p80:93ms, p95:93ms, iters:275, tasks:4 | keep order:false, stats:pseudo | 1.7549400329589844 MB | N/A | | └─TableRowIDScan_5(Probe) | 262400.00 | 0 | cop[tikv] | table:t | time:0ns, loops:0 | keep order:false, stats:pseudo | N/A | N/A | +-------------------------------+-----------+---------+-----------+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------+-----------------------+------+ 3 rows in set (0.62 sec)

执行结果的 execution info 列有 copr_cache_hit_ratio 信息，表示下推计算结果缓存的命中率。以上示例的 0.75 表示命中率大约是 75%。

查看 Grafana 监控面板

在 Grafana 监控中，tidb 命名空间下 distsql 子系统中可见 copr-cache 面板，该面板监控整个集群中下推计算结果缓存的命中次数、未命中次数和缓存丢弃次数。