当这样的小表出现大量的读查询时，会给小表数据所在的 TiKV 节点造成很大的查询压力，出现明显的读热点问题，造成集群中各个 TiKV 节点负载的不均衡，严重时会导致集群性能出现抖动、成为集群负载的瓶颈。

　　缓存表主要就是为了解决小表读热点的问题，并不针对小表的写热点，它把整张表的数据从 TiKV 加载到 TiDB Server 中进行缓存，当处理查询请求时候，直接从 TiDB Server 缓存数据中就可以完成数据查询，避免了每个查询都要访问 TiKV 节点。

　　缓存表采用 lease 机制保证从各个 TiDB Server 缓存读取跟从 TiKV 读取数据的一致性。

　　lease 代表租约，在对应的 lease 周期内，尤其是 WRITE 操作，只在 WRITE lease 内允许，一致性通过以下方式确保：

　　lease：锁到期时间，是 tso 类型，代表当前 lock_type 的有效期，如果 lease 过期，锁将会无效

　　oldReadLease：只有加 INTEND 锁的时候才会更新此列，代表读操作的结束时间，到期后可以执行写操作

　　目前版本 6.0.0 对于简单的查询，当可以通过主键或者唯一索引检索数据时候，显示走 Point_Get、Batch_Point_Get 的执行计划（有缓存数据可用，直接读缓存）。

　　其他查询会生成带有 UnionScan 算子的执行计划，针对缓存表生成的 UnionScan 算子，封装了下层的执行逻辑：

　　举例3：等待缓存过期，通过 trace 命令查看到执行从 tikv 查询数据

　　举例4：缓存数据有效，通过 trace 命令查看到执行从缓存中查询数据，不用访问 tikv.

　　对缓存表进行 DML 操作时，TiDB Server 要获取表的 WRITE lease，代表在这个租约内，可以进行表的写操作，如果要查询的数据的 snapshot 在租约内，那就不能直接使用缓存的数据，因为 TiKV 数据可能已经更新，造成缓存数据不一致，这时候需要直接查询 TiKV 获取一致的数据。

　　在 WRITE lease 内，读查询退化为跟普通表一样的从 TiKV 读取。

　　使用 sysbench 对缓存表单表进行稳定性压力测试，压测线，每个压测表的行数会变，从 50 ~ 204800 递增，表结构如下：

　　从压测数据来看，性能比较平稳，没有出现明显的波动。 2023年2月28日0时33分27秒