【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】tidb查询有结果缓存吗？ 为select * 查询0.01S，select count（） 2S，使用explain analyze 查询执行计划，耗时是一样的，但是直接select count（） 比select * 耗时长很长，查询结果只有3条
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
有缓存命中的情况的，如果查询的是一样的，刚好上次也查过，就会直接从缓存中获取了…
可以多试试，观察下
如何确定下是否走了缓存那？
有缓存，但你这种情况不一定是缓存影响的，先先多试几次
https://docs.pingcap.com/zh/tidb/stable/coprocessor-cache#使用-explain-analyze
执行结果的 execution info 列有 copr_cache_hit_ratio 信息，表示下推计算结果缓存的命中率。以上示例的 0.75 表示命中率大约是 75%。
查看 Grafana 监控面板
在 Grafana 监控中，tidb 命名空间下 distsql 子系统中可见 copr-cache 面板，该面板监控整个集群中下推计算结果缓存的命中次数、未命中次数和缓存丢弃次数。
explain analyze +sql看执行计划，里面有缓存命中率
1 个赞
explain analyze +sql copr_cache_hit_ratio 显示的都是0，执行时间是2S多，但是我真正select执行的时候确是0.01S
有结果缓存的
https://docs.pingcap.com/zh/tidb/stable/coprocessor-cache#检验缓存效果
就是这个。你后面这个时间差，证明了缓存确实存在。不然怎么可能差200倍。
是有的
有缓存
想了解什么情况下会走缓存，什么情况下不走索引
如果 SELECT * 的结果在 TiDB 的缓存中存在，那么执行速度可能会更快，因为它直接从缓存中获取结果。而 SELECT COUNT(*) 可能不会受到这种缓存效果的影响，因为它需要对实际的数据进行聚合操作。
你这两个问题，都比较复杂。
首先执行计划有缓存。
https://docs.pingcap.com/zh/tidb/stable/sql-prepared-plan-cache#prepare-语句执行计划缓存
https://docs.pingcap.com/zh/tidb/stable/sql-non-prepared-plan-cache
命中这个缓存可以跳过生成执行计划这一步。
然后tidb有缓存
https://docs.pingcap.com/zh/tidb/stable/coprocessor-cache
上面说的coprocessor-cache就是这一类。
最后tikv也有缓存，
rocksdb有block-cache
https://docs.pingcap.com/zh/tidb/stable/manage-cluster-faq#tikv-block-cache-有哪些特性
走不走索引涉及到代价评估。每种情况都不太一样。大致可以参考下面这个帖子。
研究一下，
条件是否一致？
TiDB在查询时通过TiKV缓存和TiDB Server缓存以及下推计算结果缓存来支持结果缓存，从而提高查询效率。
条件一致，
count 查询是否有缓存取决于具体的查询场景和表的特性。如果表是缓存表，并且查询可以利用缓存表的数据，那么可能会有缓存效果。如果查询需要大量的计算或者表数据不在缓存表中，那么 count 就不会受益于缓存。
sql parse有缓存，sql执行结果我理解没缓存吧，也没法缓存吧，count这种随时有可能变，如果有缓存的话什么时候过期呢