title | aliases | summary | |
---|---|---|---|
下推计算结果缓存 |
|
TiDB 4.0 支持下推计算结果缓存,配置位于 `tikv-client.copr-cache`,缓存仅存储在 TiDB 内存中,不共享缓存,对 Region 写入会导致缓存失效。缓存命中率可通过 `EXPLAIN ANALYZE` 或 Grafana 监控面板查看。 |
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 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 监控中,tidb
命名空间下 distsql
子系统中可见 copr-cache 面板,该面板监控整个集群中下推计算结果缓存的命中次数、未命中次数和缓存丢弃次数。