小表缓存适用范围

🪐 TiDB 技术问题
, ,
1

TiDB的小表缓存适用范围很高吗？
【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

2

正是环境应该很常用吧

3

正是环境应该很常用吧。

4

看业务场景了。
官方：读多写少，少于64M好像。

5

小表缓存在TiDB里还是挺实用的，但适用范围要看场景。建议优先用于以下情况：表数据量小于1GB、读多写少、查询延迟敏感。比如配置表、字典表这种经常被查询但很少更新的小表，开启缓存后性能提升明显。

操作很简单，执行：ALTER TABLE xxx CACHE; 然后查一下是否生效：SHOW CACHED TABLES;

注意：如果表频繁更新（每秒几十次以上），缓存维护成本会高，可能反而拖慢性能。生产环境建议先在小表上测试，观察一段时间。

6

大神大神

7

个人感觉 缓存表查询要独立，关联查询不缓存的大表的时候效率不高

8

适用范围很窄，仅限 64M 内、极少更新的字典表，频繁写或关联大表不建议开，租约机制会拖慢写入性能

9

仅限 64M 内、极少更新的字典表，频繁写或关联大表不建议开，租约机制会拖慢写入性能

1 个赞
10

厉害，这个我还未用过

11

字典 / 配置类小表、读多写极少、查询频繁、对读延迟敏感，开启后直接从 TiDB 内存读，绕开 TiKV，缓解 Region 读热点。

如果频繁更新、插入的表不能设置。

12

业务系统的基础词典用的多啊

13

后续学习

14

实际上可以使用的地方并不多，64MB的限制太大了，稍为大点的用户表，组织架构表都不只这个数，数据量小又没有必要用。

15

读热点的小表，可以加的呀。

16

个人感觉 缓存表查询要独立，关联查询不缓存的大表的时候效率不高

17

这边验证过，在与大表关联查询反而效率更低。原来都是下推到tikv执行。缓存后再tidbserver上执行。所以要是使用一定是独立来使用效果最好。

18

实际上可以使用的地方并不多，64MB的限制太大了，稍为大点的用户表，组织架构表都不只这个数，数据量小又没有必要用。

19

小表缓存适合数据量小、读多写少、几乎整表热点的表；表一大或写入频繁就会失效/收益下降。先确认版本是否支持及表大小阈值，用监控看命中率，不适合就靠正常缓存与索引。