1. 装完TDengine不调参数等于没装TDengine的部署看起来不难官方一条安装命令、一个systemctl脚本就能跑起来但真正上手做库表设计和数据接入时坑才一个个露出来。我自己第一次在生产环境部署TDengine时按默认配置一路点下去等到要改数据保留策略时才发现KEEP、DAYS这些参数全是建库时锁死的改起来要重建整个库。先确认你对TDengine的整体认知是否一致TDengine是一套时序数据平台核心是taosd数据库引擎进程外挂taosAdapter负责RESTful/边缘接入taosCLI是命令行交互工具。三者的关系是taosd是真正的数据库服务taosAdapter是连接器taos是客户端命令行。日常操作中到处提到的“重启taos”“进入taos”指的都是这三个组件。安装完成后第一件事不是急着建库建表而是检查两个关键点端口是否正常监听。taosd默认使用6030端口TCP供taos客户端和SDK连接taosAdapter默认使用6041端口RESTful API。如果你要通过HTTP方式写入查询6041必须通如果只是本机用taos CLI6030就够。很多新手只放行了6030结果业务端用RESTful连不上排查半天才发现是6041没开。systemd服务的守护状态。执行systemctl status taosd确认服务没有异常重启的记录。如果看到频繁的restart日志多半是资源限制问题需要调整/etc/security/limits.conf里的nofile、memlock参数。还有一个容易忽略的细节taos客户端默认连接的host是localhost端口6030。如果你是从本机直接命令行操作什么都不用配但如果想远程管理要么在taos.cfg里改fqdn要么用taos -h target-host -P 6030 -u root -p taosdata显式指定。我见过在远程机器上装了tdengine-client然后怎么敲taos都进不去的人——因为根本没指定目标服务器的地址。提示如果只是学习测试建议把taosAdapter也跑起来。因为现在很多生态工具比如Grafana数据源、各种采集器默认走RESTful接口提前把这条链路打通后面接入运维监控会省很多事。2. 建库建表的三步走普通表、子表、超级表到底怎么选2.1 先搞明白三种表的定位TDengine建表和MySQL、PostgreSQL最大的区别在于它的表结构里有硬性的时间戳主键概念并且区分普通表、子表和超级表STABLE。普通表可以独立存在有独立的表结构和数据文件适合直接按“一个设备一张表”或“一个采集点一张表”来用。子表必须挂在一个超级表下面继承超级表的列结构但可以通过TAGS标签区分不同子表的归属。超级表本质是表结构的模板 一组TAGS定义它自己不存数据数据都落在子表里。实际项目中90%的场景推荐走“超级表 子表”的路线。原因后续展开先记住一个基本判断如果你的数据天然带有“设备ID”“站点ID”“订单ID”这类可以用来打标签的维度并且查询时经常需要按这些维度筛选或聚合就用超级表。如果每个表是完全独立的、没有任何公共维度的才用普通表。2.2 建库的关键参数不能瞎填建库是TDengine操作里最需要认真对待的一步因为很多参数在建库后不能改改就得删库重建。下面是我整理出的核心参数清单每一个都标注了“推荐值”和“为什么”。参数说明推荐值选型理由KEEP数据保留天数30~365按业务设太短会丢历史数据设太长浪费磁盘DAYS数据按多少天切分文件1010天一个文件组既不过碎也不过重BLOCKS每张表内存缓存块数256适中的内存占用查询加速明显BUFFER每块内存缓存大小MB256保证写入排序缓冲不溢出CACHEMODEL缓存模型none或both默认none读写热数据可选bothPRECISION时间精度ms微秒会降低压缩率毫秒够用WAL_LEVEL日志级别1或2生产建议1兼顾安全与写入性能举个例子建一个保留30天数据、按10天分片的库CREATE DATABASE metrics KEEP 30 DAYS 10 BLOCKS 256 BUFFER 256 WAL_LEVEL 1; USE metrics;这条语句执行后metrics库就算建好了。注意WAIT参数和MAXROWS这些也需要按实际写入并发调但初期不要全调先把上面几个主参数定好跑通之后再微调。2.3 创建超级表和子表的方式超级表的创建语法比普通表多了TAGS定义。TAGS是用于筛选和聚合的元数据列不随数据点写入而变化。例如接一组温度传感器CREATE STABLE temp_sensor ( ts TIMESTAMP, temperature FLOAT, humidity FLOAT ) TAGS ( device_id BINARY(32), location BINARY(64) );之后每接入一个新设备不需要手工建一张独立子表只要通过SQL动态建子表即可CREATE TABLE temp_sensor_001 USING temp_sensor TAGS (DEV-001, Room-A);这种方式最大的好处在于后续按TAGS做过滤统计时TDengine会自动把符合条件的子表聚合起来查询逻辑统一在超级表上完成不用遍历所有普通表然后UNION这是TDengine查询快的一个底层原因。普通表的场景在什么时候用我举一个真实的例子某个项目里采集一批自定义log事件不同的log事件格式完全不同、没有公共维度这种情况下强塞进超级表反而别扭就直接建普通表CREATE TABLE log_event_xxx (ts TIMESTAMP, event_type INT, detail BINARY(512))后面按需单独查询。2.4 我的经验能用超级表就别用普通表可能有人觉得超级表麻烦多了一层“模板”概念。但TDengine的分布式查询、数据迁移和权限管理都对超级表有优化。最直观的差异是几十张普通表做统计数据汇总时你得写一长串UNION的SQL换成超级表后一行GROUP BY就搞定。在TDengine里超级表就是为物联网多设备场景设计的别绕过它去走纯普通表的路线。3. 写入操作里藏着的高频坑3.1 时间戳是主键这一点卡住了很多人TDengine每个表必须有一个时间戳列并且默认就是主键。写入时如果不显式指定时间戳TDengine会自动用当前时间填充。这在测试环境没问题但到了生产环境会有两个很痛的坑乱序写入会被丢弃或触发警告。TDengine默认按时间戳顺序写入性能最高如果你的采集端因为网络延迟、缓存堆积导致数据到达顺序颠倒后面到达的旧数据会被特殊处理。具体行为取决于版本和配置但比较常见的是被丢弃或写入变慢。解决思路是尽力让采集端按时间戳有序上报或者在客户端做本地缓存排序再批量写入。同一个表里时间戳不可重复。因为时间戳是主键同一条时间戳下再插入新数据要么被忽略要么覆盖取决于使用INSERT的语法和版本。这和我们熟悉的MySQL按自增主键完全不一样。实际写入时推荐显式带上时间戳例如INSERT INTO temp_sensor_001 VALUES (2025-01-10 08:00:00.000, 26.5, 51.2);或者用NOW函数生成时间戳INSERT INTO temp_sensor_001 VALUES (NOW, 27.1, 49.8);3.2 批量写入比逐条插入快一个量级如果你是从MySQL转过来的习惯了写循环逐条INSERT在TDengine里会非常难受。TDengine的写入性能建立在批量写入的基础上一次INSERT可以包含多行或者一条SQL插入多张表。批量写入能大幅减少网络RTT和解析开销这也是时序数据库和关系型数据库又一个明显差异。推荐的使用姿势是INSERT INTO temp_sensor_001 VALUES (2025-01-10 08:00:00.000, 26.5, 51.2), (2025-01-10 08:00:01.000, 26.6, 51.0), (2025-01-10 08:00:02.000, 26.7, 50.9);实际开发中通过SDK写入时一次提交几百到几千行是很常见的。曾经有人问我“为什么我的写入TPS只有几百”后来一看代码逐条INSERT每条一次网络往返不慢才怪。把批量大小调到500到1000行本地性能测试下写入速度能有几十倍提升。3.3 自动建表、模版化写入接入层别乱写代码TDengine的INSERT语法支持USING自动建表这意味着你的采集程序根本不用关心“新设备来了要先建表”直接写数据就能自动落库INSERT INTO temp_sensor_002 USING temp_sensor TAGS (DEV-002, Room-B) VALUES (2025-01-10 08:00:00.000, 27.3, 48.7);这样的写法特别适合设备动态接入的场景。新设备第一次上报数据时子表自动创建TAGS同时写入后续所有查询都基于这套模型自动扩展。另外值得注意的是TDengine还提供schema-less写入和参数绑定写入方式。绑定写入适合高性能场景可以理解为prepared statement省去SQL解析开销schema-less写入则适合数据格式频繁变化、不想手工维护表结构的场景。我个人的建议是常规业务用标准INSERT足够追求极致写入性能时再去研究参数绑定。4. 查询操作窗口聚合、降采样、连续查询一次讲透4.1 条件查询别踩性能陷阱TDengine的查询语法整体和SQL很接近但有几处需要注意必须用时间条件做第一过滤维度。TDengine的索引引擎是围绕时间戳设计的如果你查询不带上时间范围全表扫描性能会非常差。比如SELECT * FROM temp_sensor WHERE temperature 30这种写法会把所有子表扫描一遍线上环境CPU直接飙高。正解是先限定时间窗口再加过滤条件。标签过滤用TAGS列不要用普通列。超级表的TAGS列在元数据层就做了索引过滤效率远高于普通列。如果你要用location筛选确保创建超级表时把location定义成TAG而不是普通字段。4.2 窗口聚合是时序查询的核心玩法TDengine最常用的聚合能力是时间窗口聚合。例如统计每5分钟的平均温度SELECT _wstart, AVG(temperature) FROM temp_sensor WHERE ts 2025-01-10 08:00:00 AND ts 2025-01-10 09:00:00 INTERVAL(5m);这段SQL会按5分钟一个窗口返回每个窗口的平均温度。_wstart是窗口起始时间TDengine会自动生成。窗口聚合配合超级表时还可以用PARTITION BY把不同设备分开统计SELECT device_id, _wstart, AVG(temperature) FROM temp_sensor WHERE ts 2025-01-10 08:00:00 AND ts 2025-01-10 09:00:00 PARTITION BY device_id INTERVAL(5m);这里的device_id是TAGS列TDengine会在元数据层自动按TAGS分组再在每个分组内做窗口聚合效率极高。如果不想让窗口边界固定对齐自然时间08:00、08:05可以用SLIDE做滑动窗口比如每1分钟输出一次过去5分钟的平均值——这在监控告警场景里非常常用。4.3 连续查询让降采样和预聚合常态化很多TSDB都提供“连续查询”Continuous Query能力TDengine的连续查询也是核心特性之一适合做流式的降采样和预聚合。比如把原始秒级数据每5分钟聚合一次存入另一个超级表长期保留原始数据则可以缩短KEEP。创建连续查询的语法CREATE CONTINUOUS QUERY avg_temp_5m ON metrics BEGIN SELECT _wstart, device_id, AVG(temperature) INTO avg_temp_5m FROM temp_sensor PARTITION BY device_id INTERVAL(5m) END;开启后TDengine会按时间窗口自动执行聚合并把结果写入avg_temp_5m表。这个功能不需要额外部署流处理框架纯数据库内部完成业务上省掉一套独立的实时计算组件。我自己的经验是连续查询尽量在业务初期就规划好而不是等数据量大了再回头补。因为如果原始数据KEEP设置得很短比如7天过了窗口期再去补历史聚合结果原始数据已经没了预聚合表也就永远缺一块。4.4 TOP、LAST、SPREAD等时序函数的实用价值TDengine自带一批时序业务函数例如LAST最新值、FIRST最早值、SPREAD最大值与最小值之差、TWA时间加权平均值以及TOP取前几条。这些在设备状态判断和异常检测场景中很好用。举个例子查看每个设备当前的温度、湿度SELECT LAST(ts), LAST(temperature), LAST(humidity) FROM temp_sensor GROUP BY device_id;注意这里的做法是在超级表上按TAGS的device_id分组后取每组的最后一条数据。如果用普通表来做这个需求得先知道有哪些表再逐张查然后合并麻烦太多了。5. 数据维护与常见问题排查5.1 删除、清空、销毁三个操作意义完全不同DELETE删除指定时间范围内的数据点。注意TDengine的DELETE是可以指定时间范围的不像某些TSDB只能删整表。DELETE FROM temp_sensor_001 WHERE ts 2025-01-10 00:00:00 AND ts 2025-01-10 01:00:00;DROP TABLE删除整张表如果是子表则将其从超级表移除。DROP STABLE删除超级表及其所有子表。这个操作很重执行前务必备份没有回滚机制。5.2 磁盘占用只增不减先检查这几个点TDengine的自研存储引擎在处理数据删除时不会立刻归还磁盘空间而是先做逻辑删除等后续合并或压缩时才真正回收。所以如果你刚执行了DELETE或大量覆盖写发现磁盘没降下来别慌这是正常现象。想立即回收物理空间主要看压缩任务执行情况通常需要等待后台合并完成。另外数据库的默认配置里如果KEEP 365且业务每天写入量大磁盘增长会非常快。在监控里给数据目录单独挂一块盘别让系统盘和数据盘混在一起同时给目录空间配好告警通常到80%就要介入处理。5.3 登录失败、无法连接检查这几处配置用户名密码默认root/taosdata。如果改过密码又忘记了需要到服务器上处理。权限默认root拥有超级权限但建子用户时需要注意授权范围TDengine的权限粒度是“库级别”。网络跨机器访问时除了6030/6041端口还要确认两台机器的时间是否同步。TDengine对时间同步要求很高时钟漂移会直接影响时序数据的写入和查询。5.4 数据迁移的思路如果要把A机器上的TDengine数据迁到B机器最直接的方式是先在B机器建同结构的库表再通过查询导出导入。不过TDengine本身提供了备份工具和方案业务量大的场景建议参考官方备份恢复文档来做而不是手工导CSV——手工导出导入在数据量大到一定程度后会非常折磨人。6. 我的最终建议TDengine的“常用操作”表面上就是建库建表、写入查询、维护管理这几板斧但这套操作背后体现的时序思维是需要花时间体会的。不要拿MySQL/PostgreSQL的心智模型硬套在TDengine上在MySQL里你可能会为每个设备单独建一张表然后在应用层写各种JOIN和UNION在TDengine里正确做法是一张超级表挂所有设备、用TAGS做维度、在数据库内部完成聚合——架构对了后续扩展和运维都会越用越顺。另外生产环境一定要规划好KEEP、DAYS、BLOCKS这些建库参数因为改库成本很高。数据模型尽量从第一版就定成“超级表子表TAGS”不要等业务量上来之后再来翻工。最后别忘了给taosd的日志和数据目录各留足磁盘空间避免日志把系统盘撑爆导致整个服务不可用的尴尬局面。 
长河君 · 2026/9/13 3:41:47 · 阅读 1.2k TDengine实战指南：从超级表建模到查询优化，避开常见坑
1. 装完TDengine不调参数等于没装TDengine的部署看起来不难官方一条安装命令、一个systemctl脚本就能跑起来但真正上手做库表设计和数据接入时坑才一个个露出来。我自己第一次在生产环境部署TDengine时按默认配置一路点下去等到要改数据保留策略时才发现KEEP、DAYS这些参数全是建库时锁死的改起来要重建整个库。先确认你对TDengine的整体认知是否一致TDengine是一套时序数据平台核心是taosd数据库引擎进程外挂taosAdapter负责RESTful/边缘接入taosCLI是命令行交互工具。三者的关系是taosd是真正的数据库服务taosAdapter是连接器taos是客户端命令行。日常操作中到处提到的“重启taos”“进入taos”指的都是这三个组件。安装完成后第一件事不是急着建库建表而是检查两个关键点端口是否正常监听。taosd默认使用6030端口TCP供taos客户端和SDK连接taosAdapter默认使用6041端口RESTful API。如果你要通过HTTP方式写入查询6041必须通如果只是本机用taos CLI6030就够。很多新手只放行了6030结果业务端用RESTful连不上排查半天才发现是6041没开。systemd服务的守护状态。执行systemctl status taosd确认服务没有异常重启的记录。如果看到频繁的restart日志多半是资源限制问题需要调整/etc/security/limits.conf里的nofile、memlock参数。还有一个容易忽略的细节taos客户端默认连接的host是localhost端口6030。如果你是从本机直接命令行操作什么都不用配但如果想远程管理要么在taos.cfg里改fqdn要么用taos -h target-host -P 6030 -u root -p taosdata显式指定。我见过在远程机器上装了tdengine-client然后怎么敲taos都进不去的人——因为根本没指定目标服务器的地址。提示如果只是学习测试建议把taosAdapter也跑起来。因为现在很多生态工具比如Grafana数据源、各种采集器默认走RESTful接口提前把这条链路打通后面接入运维监控会省很多事。2. 建库建表的三步走普通表、子表、超级表到底怎么选2.1 先搞明白三种表的定位TDengine建表和MySQL、PostgreSQL最大的区别在于它的表结构里有硬性的时间戳主键概念并且区分普通表、子表和超级表STABLE。普通表可以独立存在有独立的表结构和数据文件适合直接按“一个设备一张表”或“一个采集点一张表”来用。子表必须挂在一个超级表下面继承超级表的列结构但可以通过TAGS标签区分不同子表的归属。超级表本质是表结构的模板 一组TAGS定义它自己不存数据数据都落在子表里。实际项目中90%的场景推荐走“超级表 子表”的路线。原因后续展开先记住一个基本判断如果你的数据天然带有“设备ID”“站点ID”“订单ID”这类可以用来打标签的维度并且查询时经常需要按这些维度筛选或聚合就用超级表。如果每个表是完全独立的、没有任何公共维度的才用普通表。2.2 建库的关键参数不能瞎填建库是TDengine操作里最需要认真对待的一步因为很多参数在建库后不能改改就得删库重建。下面是我整理出的核心参数清单每一个都标注了“推荐值”和“为什么”。参数说明推荐值选型理由KEEP数据保留天数30~365按业务设太短会丢历史数据设太长浪费磁盘DAYS数据按多少天切分文件1010天一个文件组既不过碎也不过重BLOCKS每张表内存缓存块数256适中的内存占用查询加速明显BUFFER每块内存缓存大小MB256保证写入排序缓冲不溢出CACHEMODEL缓存模型none或both默认none读写热数据可选bothPRECISION时间精度ms微秒会降低压缩率毫秒够用WAL_LEVEL日志级别1或2生产建议1兼顾安全与写入性能举个例子建一个保留30天数据、按10天分片的库CREATE DATABASE metrics KEEP 30 DAYS 10 BLOCKS 256 BUFFER 256 WAL_LEVEL 1; USE metrics;这条语句执行后metrics库就算建好了。注意WAIT参数和MAXROWS这些也需要按实际写入并发调但初期不要全调先把上面几个主参数定好跑通之后再微调。2.3 创建超级表和子表的方式超级表的创建语法比普通表多了TAGS定义。TAGS是用于筛选和聚合的元数据列不随数据点写入而变化。例如接一组温度传感器CREATE STABLE temp_sensor ( ts TIMESTAMP, temperature FLOAT, humidity FLOAT ) TAGS ( device_id BINARY(32), location BINARY(64) );之后每接入一个新设备不需要手工建一张独立子表只要通过SQL动态建子表即可CREATE TABLE temp_sensor_001 USING temp_sensor TAGS (DEV-001, Room-A);这种方式最大的好处在于后续按TAGS做过滤统计时TDengine会自动把符合条件的子表聚合起来查询逻辑统一在超级表上完成不用遍历所有普通表然后UNION这是TDengine查询快的一个底层原因。普通表的场景在什么时候用我举一个真实的例子某个项目里采集一批自定义log事件不同的log事件格式完全不同、没有公共维度这种情况下强塞进超级表反而别扭就直接建普通表CREATE TABLE log_event_xxx (ts TIMESTAMP, event_type INT, detail BINARY(512))后面按需单独查询。2.4 我的经验能用超级表就别用普通表可能有人觉得超级表麻烦多了一层“模板”概念。但TDengine的分布式查询、数据迁移和权限管理都对超级表有优化。最直观的差异是几十张普通表做统计数据汇总时你得写一长串UNION的SQL换成超级表后一行GROUP BY就搞定。在TDengine里超级表就是为物联网多设备场景设计的别绕过它去走纯普通表的路线。3. 写入操作里藏着的高频坑3.1 时间戳是主键这一点卡住了很多人TDengine每个表必须有一个时间戳列并且默认就是主键。写入时如果不显式指定时间戳TDengine会自动用当前时间填充。这在测试环境没问题但到了生产环境会有两个很痛的坑乱序写入会被丢弃或触发警告。TDengine默认按时间戳顺序写入性能最高如果你的采集端因为网络延迟、缓存堆积导致数据到达顺序颠倒后面到达的旧数据会被特殊处理。具体行为取决于版本和配置但比较常见的是被丢弃或写入变慢。解决思路是尽力让采集端按时间戳有序上报或者在客户端做本地缓存排序再批量写入。同一个表里时间戳不可重复。因为时间戳是主键同一条时间戳下再插入新数据要么被忽略要么覆盖取决于使用INSERT的语法和版本。这和我们熟悉的MySQL按自增主键完全不一样。实际写入时推荐显式带上时间戳例如INSERT INTO temp_sensor_001 VALUES (2025-01-10 08:00:00.000, 26.5, 51.2);或者用NOW函数生成时间戳INSERT INTO temp_sensor_001 VALUES (NOW, 27.1, 49.8);3.2 批量写入比逐条插入快一个量级如果你是从MySQL转过来的习惯了写循环逐条INSERT在TDengine里会非常难受。TDengine的写入性能建立在批量写入的基础上一次INSERT可以包含多行或者一条SQL插入多张表。批量写入能大幅减少网络RTT和解析开销这也是时序数据库和关系型数据库又一个明显差异。推荐的使用姿势是INSERT INTO temp_sensor_001 VALUES (2025-01-10 08:00:00.000, 26.5, 51.2), (2025-01-10 08:00:01.000, 26.6, 51.0), (2025-01-10 08:00:02.000, 26.7, 50.9);实际开发中通过SDK写入时一次提交几百到几千行是很常见的。曾经有人问我“为什么我的写入TPS只有几百”后来一看代码逐条INSERT每条一次网络往返不慢才怪。把批量大小调到500到1000行本地性能测试下写入速度能有几十倍提升。3.3 自动建表、模版化写入接入层别乱写代码TDengine的INSERT语法支持USING自动建表这意味着你的采集程序根本不用关心“新设备来了要先建表”直接写数据就能自动落库INSERT INTO temp_sensor_002 USING temp_sensor TAGS (DEV-002, Room-B) VALUES (2025-01-10 08:00:00.000, 27.3, 48.7);这样的写法特别适合设备动态接入的场景。新设备第一次上报数据时子表自动创建TAGS同时写入后续所有查询都基于这套模型自动扩展。另外值得注意的是TDengine还提供schema-less写入和参数绑定写入方式。绑定写入适合高性能场景可以理解为prepared statement省去SQL解析开销schema-less写入则适合数据格式频繁变化、不想手工维护表结构的场景。我个人的建议是常规业务用标准INSERT足够追求极致写入性能时再去研究参数绑定。4. 查询操作窗口聚合、降采样、连续查询一次讲透4.1 条件查询别踩性能陷阱TDengine的查询语法整体和SQL很接近但有几处需要注意必须用时间条件做第一过滤维度。TDengine的索引引擎是围绕时间戳设计的如果你查询不带上时间范围全表扫描性能会非常差。比如SELECT * FROM temp_sensor WHERE temperature 30这种写法会把所有子表扫描一遍线上环境CPU直接飙高。正解是先限定时间窗口再加过滤条件。标签过滤用TAGS列不要用普通列。超级表的TAGS列在元数据层就做了索引过滤效率远高于普通列。如果你要用location筛选确保创建超级表时把location定义成TAG而不是普通字段。4.2 窗口聚合是时序查询的核心玩法TDengine最常用的聚合能力是时间窗口聚合。例如统计每5分钟的平均温度SELECT _wstart, AVG(temperature) FROM temp_sensor WHERE ts 2025-01-10 08:00:00 AND ts 2025-01-10 09:00:00 INTERVAL(5m);这段SQL会按5分钟一个窗口返回每个窗口的平均温度。_wstart是窗口起始时间TDengine会自动生成。窗口聚合配合超级表时还可以用PARTITION BY把不同设备分开统计SELECT device_id, _wstart, AVG(temperature) FROM temp_sensor WHERE ts 2025-01-10 08:00:00 AND ts 2025-01-10 09:00:00 PARTITION BY device_id INTERVAL(5m);这里的device_id是TAGS列TDengine会在元数据层自动按TAGS分组再在每个分组内做窗口聚合效率极高。如果不想让窗口边界固定对齐自然时间08:00、08:05可以用SLIDE做滑动窗口比如每1分钟输出一次过去5分钟的平均值——这在监控告警场景里非常常用。4.3 连续查询让降采样和预聚合常态化很多TSDB都提供“连续查询”Continuous Query能力TDengine的连续查询也是核心特性之一适合做流式的降采样和预聚合。比如把原始秒级数据每5分钟聚合一次存入另一个超级表长期保留原始数据则可以缩短KEEP。创建连续查询的语法CREATE CONTINUOUS QUERY avg_temp_5m ON metrics BEGIN SELECT _wstart, device_id, AVG(temperature) INTO avg_temp_5m FROM temp_sensor PARTITION BY device_id INTERVAL(5m) END;开启后TDengine会按时间窗口自动执行聚合并把结果写入avg_temp_5m表。这个功能不需要额外部署流处理框架纯数据库内部完成业务上省掉一套独立的实时计算组件。我自己的经验是连续查询尽量在业务初期就规划好而不是等数据量大了再回头补。因为如果原始数据KEEP设置得很短比如7天过了窗口期再去补历史聚合结果原始数据已经没了预聚合表也就永远缺一块。4.4 TOP、LAST、SPREAD等时序函数的实用价值TDengine自带一批时序业务函数例如LAST最新值、FIRST最早值、SPREAD最大值与最小值之差、TWA时间加权平均值以及TOP取前几条。这些在设备状态判断和异常检测场景中很好用。举个例子查看每个设备当前的温度、湿度SELECT LAST(ts), LAST(temperature), LAST(humidity) FROM temp_sensor GROUP BY device_id;注意这里的做法是在超级表上按TAGS的device_id分组后取每组的最后一条数据。如果用普通表来做这个需求得先知道有哪些表再逐张查然后合并麻烦太多了。5. 数据维护与常见问题排查5.1 删除、清空、销毁三个操作意义完全不同DELETE删除指定时间范围内的数据点。注意TDengine的DELETE是可以指定时间范围的不像某些TSDB只能删整表。DELETE FROM temp_sensor_001 WHERE ts 2025-01-10 00:00:00 AND ts 2025-01-10 01:00:00;DROP TABLE删除整张表如果是子表则将其从超级表移除。DROP STABLE删除超级表及其所有子表。这个操作很重执行前务必备份没有回滚机制。5.2 磁盘占用只增不减先检查这几个点TDengine的自研存储引擎在处理数据删除时不会立刻归还磁盘空间而是先做逻辑删除等后续合并或压缩时才真正回收。所以如果你刚执行了DELETE或大量覆盖写发现磁盘没降下来别慌这是正常现象。想立即回收物理空间主要看压缩任务执行情况通常需要等待后台合并完成。另外数据库的默认配置里如果KEEP 365且业务每天写入量大磁盘增长会非常快。在监控里给数据目录单独挂一块盘别让系统盘和数据盘混在一起同时给目录空间配好告警通常到80%就要介入处理。5.3 登录失败、无法连接检查这几处配置用户名密码默认root/taosdata。如果改过密码又忘记了需要到服务器上处理。权限默认root拥有超级权限但建子用户时需要注意授权范围TDengine的权限粒度是“库级别”。网络跨机器访问时除了6030/6041端口还要确认两台机器的时间是否同步。TDengine对时间同步要求很高时钟漂移会直接影响时序数据的写入和查询。5.4 数据迁移的思路如果要把A机器上的TDengine数据迁到B机器最直接的方式是先在B机器建同结构的库表再通过查询导出导入。不过TDengine本身提供了备份工具和方案业务量大的场景建议参考官方备份恢复文档来做而不是手工导CSV——手工导出导入在数据量大到一定程度后会非常折磨人。6. 我的最终建议TDengine的“常用操作”表面上就是建库建表、写入查询、维护管理这几板斧但这套操作背后体现的时序思维是需要花时间体会的。不要拿MySQL/PostgreSQL的心智模型硬套在TDengine上在MySQL里你可能会为每个设备单独建一张表然后在应用层写各种JOIN和UNION在TDengine里正确做法是一张超级表挂所有设备、用TAGS做维度、在数据库内部完成聚合——架构对了后续扩展和运维都会越用越顺。另外生产环境一定要规划好KEEP、DAYS、BLOCKS这些建库参数因为改库成本很高。数据模型尽量从第一版就定成“超级表子表TAGS”不要等业务量上来之后再来翻工。最后别忘了给taosd的日志和数据目录各留足磁盘空间避免日志把系统盘撑爆导致整个服务不可用的尴尬局面。