读缓存cachemodel咨询

TDuser_pM9V_5910 · 2026 年10 月 13 日 06:29

【TDengine 使用环境】生产
生产环境 /测试/ Poc/预生产环境

【TDengine 版本】3.3.2

【操作系统以及版本】cento7.9

【部署方式】容器/非容器部署非容器

【集群节点数】3

【集群副本数】3

我的cachemodel设置的是both 想last函数走缓存我想请问下这边ai给出一个这个信息

TDengine 的机制：子表一旦收到乱序数据（时间戳比已存的旧数据被后写入），该表的 last 缓存即失效，之后对它的 LAST 查询退化为扫描。配置 CACHEMODEL both 只保证“缓存在维护”，挡不住“被作废”

涛思有这个机制吗一旦出现这种情况就会失效???

TDuser_Apjn_2453 · 2026 年10 月 13 日 09:24

缓存机制不会失效，但是乱序会造成数据污染。
例如：你向表中写入一条2099年的数据，那么即使今天的数据不断写入，last返回的仍然是2099年的数据。

last/last_row 返回的是时间戳最大的数据，不是最近写入的数据。

TDuser_pM9V_5910 · 2026 年10 月 13 日 09:31

那我这边做了一个测试在cache为none的时候使用此sql SELECT LAST(result) result,tbname, s, u

FROM mydb_unit8.super_point_18_2

GROUP BY tbname order by s;查询花费时间7s 然后再改成both之后还是相同的sql 还是7s 并没有明显的变化这是为啥

TDuser_Apjn_2453 · 2026 年10 月 13 日 09:34

explain analyze SQL
看下执行计划，是否走了缓存。

TDuser_pM9V_5910 · 2026 年10 月 13 日 09:35

这是explain的结果有点不是很懂这个怎么看

TDuser_Apjn_2453 · 2026 年10 月 13 日 09:40

表结构和完整SQL提供一下，上面的执行计划走的是全部扫描

TDuser_pM9V_5910 · 2026 年10 月 13 日 09:42

这个是超级表 CREATE STABLE super_point_18_2 (ts TIMESTAMP ENCODE ‘delta-i’ COMPRESS ‘lz4’ LEVEL ‘medium’, result DOUBLE ENCODE ‘delta-d’ COMPRESS ‘lz4’ LEVEL ‘medium’) TAGS (s VARCHAR(20), u VARCHAR(20))

这个就是SELECT LAST(result) result,tbname, s, u

FROM mydb_unit8.super_point_18_2

GROUP BY tbname order by s;执行计划的 sql

TDuser_Apjn_2453 · 2026 年10 月 13 日 09:52

这个SQL应该是走缓存的。
你看下修改后的 cachemodel 是否生效（show create database 数据库）,以及 cachesize 大小。

show 数据库.vgroups；查看 cacheload(缓存空间) 和cacheelement(缓存对象数量) 是否在数据写入后产生变化。

TDuser_pM9V_5910 · 2026 年10 月 13 日 09:59

CREATE DATABASE mydb_unit8 BUFFER 16 CACHESIZE 15 CACHEMODEL ‘both’ COMP 2 DURATION 61d WAL_FSYNC_PERIOD 3000 MAXROWS 4096 MINROWS 100 STT_TRIGGER 1 KEEP 3650d,3650d,3650d PAGES 256 PAGESIZE 4 PRECISION ‘ms’ REPLICA 1 WAL_LEVEL 1 VGROUPS 2 SINGLE_STABLE 0 TABLE_PREFIX 0 TABLE_SUFFIX 0 TSDB_PAGESIZE 4 WAL_RETENTION_PERIOD 3600 WAL_RETENTION_SIZE 0 KEEP_TIME_OFFSET 0h ENCRYPT_ALGORITHM ‘none’ S3_CHUNKPAGES 131072 S3_KEEPLOCAL 525600m S3_COMPACT 1 COMPACT_INTERVAL 0d COMPACT_TIME_RANGE 0d,0d COMPACT_TIME_OFFSET 0h

这是建库语句

如果走了缓存还会这么慢吗

TDuser_Apjn_2453 · 2026 年10 月 13 日 10:05

看建库语句是开启了缓存。如果从缓存查询，应该在ms级别返回。

TDuser_pM9V_5910 · 2026 年10 月 13 日 10:14

那现在这么慢该如何解决呢哪里不太对

TDuser_Apjn_2453 · 2026 年10 月 14 日 00:36

explain analyze select last(*) from 表; 看下执行计划和执行时间。

TDuser_pM9V_5910 · 2026 年10 月 14 日 00:57

这个倒是执行的挺快的

TDuser_Apjn_2453 · 2026 年10 月 14 日 00:59

这个 Last Row Scan 说明走缓存查询

TDuser_pM9V_5910 · 2026 年10 月 14 日 00:59

不过我的业务需求其实是要查询这个超级表现下面所有子表的最新数据

TDuser_Apjn_2453 · 2026 年10 月 14 日 01:03

explain analyze select last(*) from 超级表 group by tbname; 看下执行计划
逐步排查一下

TDuser_pM9V_5910 · 2026 年10 月 14 日 01:06

这个也挺快

TDuser_Apjn_2453 · 2026 年10 月 14 日 01:52

那就用开始的sql在看下执行计划吧。看是否是 order by 导致了执行计划有问题。。

TDuser_pM9V_5910 · 2026 年10 月 14 日 02:24

我用一开始的sql去掉了order by 执行计划如下: 还是很慢

然后我是去掉group by 保留order by ,很快 ,执行计划如下:

TDuser_pM9V_5910 · 2026 年10 月 14 日 02:24

目前看是这个group by导致的