现在有一张维表，数据量不到十万条，现在将其设置为缓存表，这个表会每小时进行更新，现在发现慢查询的sql里，读取缓存表时 get_snapshot_time时间很长。这是否意味着因为历史数据过多引起的，也就是说数据更新后，tidb 从tikv拉取缓存表到内存的时候涉及的历史版本太多了呢，目前只保留最近两个小时的变化，理论上最多也就是当前总量*2，也不到二十万数据啊，但看一些慢查询的sql，有时get_snapshot_time 都好几秒。这可能是什么原因引起的呢
是不是数据量太大了
我说了啊，数据量不大，不到十万，加上历史版本，极端情况也不会超过20万
执行计划发出来看看
64M以上的表就不允许当作缓存表使用了，你这十万条倒是不是很大，但是你这个每小时更新，不太适合吧，你可以看下mysql.table_cache_meta这个表是否有锁，和锁租约 lease的相关信息。
1 个赞
看看执行计划到底有没有命中缓存。
缓存表的使用其中有一条，数据非经常变化的。变化频率为一小时。
另外表的行数大小没什么吧，主要看大小。
只是这个缓存表有这问题吗
缓存表不适合更新，最好不动
1 个赞
发一下执行计划，看看里面的扫描版本是不是很多？
可以检查一下tikv的存储是否存在Io瓶颈。
看看执行计划？
从你每小时都需要更新的场景来说，这种就不是很适合使用缓存表，缓存表更新还是比较慢和麻烦，缓存表比较适合更新频率比较低和更新数据量比较小的场景。
1 个赞
看看是不是数据量过大。
如果缓存表涉及频繁的写入操作，可能会导致写入热点，影响读取性能。
看看执行计划
看下执行计划，分析哪一步慢。再进行优化。同时也要看看系统的负载情况，比如CPU，内存，磁盘IO。
看看是不是缓存表过大导致的。