v7.5.0 开始兼容mysql8.0. mysql8.0后查询缓存这个功能被淘汰了。tidb对这个功能(查询缓存)的使用？是关闭好还是启用好？
show VARIABLES like ‘%query_cache%’; 命令查看是启用这个参数的。
mysql 8.0的查询缓存已被弃用，8.0.20已完全移除，这个功能弊远大于利。
tidb中似乎没有听说有查询缓存的功能。类似的只有小表缓存，小表缓存是支持的，默认最大64M的表可以进行小表缓存。
1 个赞
tidb-server 有条件地支持执行计划的缓存，对于完整的查询结果在tidb-server中暂不支持。缓存的使用，不仅命中率比较低，还会带来内存管理的诸多问题。
不过，在tidb-server有一个Coprocessor Cache 缓存，这个主要是缓存以region 为维度的查询结果, 是下推计算结果的缓存。缓存仅存储在 TiDB 内存中，TiDB 重启后缓存会失效，不同 TiDB 实例之间不共享缓存。即使缓存命中，后续仍有 TiDB 计算。
由于对 Region 的写入会导致涉及该 Region 的缓存失效，该功能主要会对很少变更的数据有效果。
https://docs.pingcap.com/zh/tidb/stable/coprocessor-cache#配置
1 个赞
没听说过TiDB有查询缓存的功能
分布式数据库查询缓存很难做，消耗资源比单机多多了。目前还不支持
TiDB使用regine cache做查询缓存的功能，从不同数据库的设计来看，缓存的功能多是有的，具体情况考虑可能不同
目前还不支持查询缓存，支持小表缓存
只有小表缓存，刚考完 
TiDB没有查询缓存，小表缓存也没快很多
在一些读取比较小的配置表、静态全局表（几十行、几百行）场景，性能提升还是很明显的。
我们有一个场景是flink去join一些配置表，QPS有几万，改为小表缓存后 join SQL延迟从10ms 下降到2ms 左右，速度提升了不少。
可能你那个表真的小，我测试10万条数据库的3个表都放小表缓存，然后join也没快多少，返回是一两条数据的
小表缓存这个是需要配置么？还是他自己根据查询热度缓存
自己设置，设置后不适合更新和修改这个表，要转成未缓存才能改
在tidb 这个配置 是启用状态 。发布这个主题的的目的是想深入了解下这个缓存的使用。
如果tidb不支持。这个配置是否有其他的用途？还是有些代码只是借用mysql的。虽然有，但是没用。
tidb有小表缓存，这个小表最好是一般没有ddl和dml操作的表
缓存表 | PingCAP 文档中心
1 个赞
热点小表把整个小表缓存在内存，通过读写锁保证数据的一致性。感觉更像redis的用法。
查询缓存提高了完全相同的查询语句的响应速度。MySQL Server 会对查询语句进行 Hash 计算得到一个 Hash 值。得到 Hash 值之后，通过该值到查询缓存中匹配该查询的结果。
如果匹配，则将查询的结果集直接返回给客户端，不必再解析、执行查询。一定程度提高性能。
如果没有匹配，则将 Hash 值和结果集保存在查询缓存中，以便以后使用。也就是说，一个查询语句（select）到了 MySQL Server 之后，会先到查询缓存看看，如果曾经执行过的话，就直接返回结果集给客户端。
提出该问题，起初，只是迷惑这个功能到底是什么，慢慢的有些明白，如果了解些分布式系统所用的分布式缓存技术的话，可能心里会明朗些。
总而言之，有很多不懂的，需要自己潜心研究，若想进步快些，就得多发布主题，志同道合者一起探讨，促进进步。
官方文档这么写的“由于应用和连接器通常需要读取 MySQL 变量，为了兼容这一需求，在 TiDB 中，部分 MySQL 的变量既可读取也可设置。例如，尽管 JDBC 连接器不依赖于查询缓存 (query cache) 的行为，但仍然可以读取和设置查询缓存。”
好的，大体了解。
集群类数据库，感觉查询缓存命中率不高，小表缓存可以用用