# [FAQ] 大数据量的 count 查询为什么第二次执行比第一次快很多

## Key Words

SQL_NO_CACHE，Coprocessor Cache

## Description

SQL_CACHE/SQL_NO_CACHE 用于控制是否把请求结果缓存到 TiKV RocksDB 的 BlockCache 中，对于一次性的大数据量查询，比如 count 查询，为了避免冲掉 BlockCache 中的热点数据，加上了 SQL_NO_CACHE，但实际测试发现第二次查询同样的 SQL 还是要快很多，是有什么原理吗？

## Content

TiDB 从 v4.0 开始支持下推计算结果缓存（Coprocessor Cache），自 v5.0 起该功能默认开启，第二次执行相同 SQL，TiDB 实例侧会缓存下推给 TiKV 计算的结果，从而起到加速的效果。

可以通过执行 EXPLAIN ANALYZE 或查看 Grafana 监控面板来检查 Coprocessor 的缓存效果

- 执行计划 execution info 中的 copr_cache_hit_ratio 字段显示当前 SQL 执行时的缓存命中率

- TiDB 监控页面下的 Distsql - Coprocessor Cache 面板显示整个集群缓存的命中和未命中次数

如果希望测试 SQL_NO_CACHE 的效果，可以单独启动一个 TiDB 实例，设置参数 tikv-client.copr-cache.capacity-mb 为 0.0 以关闭 Coprocessor Cache 功能。

## Affected Versions

v4.0 及以上版本