远程抄表数据存储优化：从MySQL到TDengine的实战经验

先说个真实场景。去年做某个水务集团的分区计量项目，光一个区就挂了八万多只智能水表，采集频率从每天一次逐步提到十五分钟一次。数据库从Oracle换成MySQL，又从MySQL单库拆到分表，最后发现一个尴尬的事实：无论怎么调优，按天做全量用水量统计的SQL都要跑十几分钟，晚间用水低谷期还得靠人工补录数据。当时我就确信，远程抄表这个场景，缺的不是数据库运维能力，而是一个从模型上就贴合时序数据特性的存储引擎。后来换上TDengine，同样一张统计报表，从十几分钟降到三秒以内，存储占用还缩到原来的十分之一。这篇就把我踩过的坑、验证过的方案和具体落地步骤完整写出来，给正在做智慧水务建设的朋友一个参考。

1. 远程抄表场景下，数据存储问题卡在哪儿

1.1 智能水表产生的数据，远比想象中要多

很多刚接触智慧水务的人，对“远程抄表”的数据量没有直观概念。总觉得一只水表一天上报几十条数据，能有多少？算一下就知道了。一个中等规模水司，管理的水表量通常在一万到几十万只之间。我们就按十万只水表来算，每只表十五分钟上报一条抄表数据，一天的记录数是：

• 10万只 × 每天96条 = 960万条，约一千万条；
• 一年就是36.5亿条，约40亿条；
• 如果再把压力传感器、流量计、水质监测仪的数据算进来，总量还得再翻一两倍。

这个数据量对OLTP系统来说，其实还能扛，但真正的麻烦在于远程抄表的数据模型是随时间无限增长的追加写入，而且查询习惯非常固定：按小区、按户、按时间段查用水曲线，按日跑汇总，按季度做对比。传统关系型数据库，表一旦到亿级，即使索引建得再合理，多维度的时序聚合查询也会把CPU打到百分之百，慢得让人怀疑人生。

1.2 传统数据库在时序数据面前的硬伤

远程抄表数据本质上是一批时序数据，有明确的时间戳、设备标识和测点值，和订单、用户这种行式业务数据完全不同。但早期智慧水务项目多是直接沿用关系型数据库存储，这就带来几个绕不开的问题。

第一是存储膨胀。行式存储按行连续存放，一条抄表记录里即使只有三个字段有意义，也得跟着表结构把整行占满。水表读数、流量、压力、状态位、上报时间、设备编号……一条记录在MySQL里轻松占掉三四百字节。累积到几十亿条以后，磁盘空间就变成了天文数字。

第二是写入吞吐。大量智能水表集中在每个整点或半点上报，写入是典型的“脉冲式”峰值。MySQL的索引维护和行锁机制在千万级写入面前非常吃力，经常出现写入积压、延迟，导致次日的日结数据不准确。

第三是聚合查询效率低。按小区统计今日用水量，本质是对一段时间范围内的大量行做扫描再聚合。关系型数据库在这个场景下没有有效的时间排序存储结构，只能全表扫，时间越长越慢。

这就是为什么智慧水务项目做到一定规模，大家不约而同地转向时序数据库。而我最终选择TDengine，不只是因为它能解决上面三个问题，更因为它的数据模型和抄表场景的契合度实在太高了。

2. 为什么TDengine能在水务场景站住脚

2.1 时序数据模型与抄表数据天然匹配

选型阶段我也对比过InfluxDB、TimescaleDB，最后选TDengine有几个非常实际的原因。首先是它提出的“超级表（STable）”概念，恰好对应远程抄表的业务结构：一块智能水表一张子表，所有水表共享同一个超级表模板，水表的静态属性（户号、小区、片区、表型）作为标签存储，动态采集值作为数据列存储。

这个设计对业务的友好程度是巨大的。按小区统计用水量，不需要再盯着“where小区=xx”去扫全表，而是按标签直接定位到一组子表；按户查历史曲线，就是查一张子表；按时间区间聚合，底层数据已经按时间排序，扫描范围被极大缩小。

对比之下，InfluxDB用measurement+tag的模型也接近，但在处理“上百张表每天各写入数十条”的场景时，它的索引开销明显偏高。TimescaleDB本质是PostgreSQL扩展，存储还是行式，压缩需要手动开启而且维护成本高。TDengine天生就是按“一个设备一张表”的模型设计的，对这个场景来说不需要任何思维转换。

2.2 列式存储和压缩能力，直接决定存储成本

存储成本是水司最敏感的话题之一。财报里IT支出大头不是服务器采购，而是存储扩容。TDengine用了列式存储加时间块压缩，这一点在时序场景下带来的收益非常明显。

先说一下背后的逻辑。列式存储把同一列的数据连续存放，这样水表读数、流量值这些同类型、同量纲的数据集中在一起，压缩算法可以针对每个列的特点来选。比如水表读数通常变化平缓，用delta-delta编码加simple-8b压缩，效果远远好于把整行塞在一起压缩。而且TDengine底层按时间分块，每块数据的时间戳是递增的，时间列可以压缩得极狠。

我自己的实测数据：同样一批抄表记录，MySQL里占了约2.1TB（含索引），导入TDengine后压缩到不到200GB。后来查了官方文档，不同场景压缩比有所差异，但列式存储+时间块压缩带来的空间节省，任何一个水司做了都会吓一跳。

2.3 从关系型数据库迁过来的实际体会

迁数据的时候我做了个对比实验：同一台服务器，MySQL单表存了约5亿条用水记录，TDengine超级表同样存5亿条，查询“某小区过去30天逐日用水量”这个典型的日结报表。

这个对比公平吗？也不算完全公平，毕竟MySQL本来就不该干这活。但它说服了项目组里的所有人：换了存储引擎之后，同样的服务器数量，能支撑的水表规模至少大了一个数量级。这也是我在后面所有方案设计里，坚持把TDengine作为抄表数据核心存储的理由。

3. 落地过程：建库、建表、写入与查询实操

3.1 安装部署：Linux环境为主，Windows注意这几个问题

先说说部署。生产环境强烈建议用Linux，我这边用的CentOS 7.9，当然Ubuntu 20.04/22.04也完全没问题。TDengine分企业版和社区版，社区版功能对智慧水务项目来说完全够用，而且开源免费，没有授权过期问题，这是重点，后面踩坑部分会细说。

安装流程其实很常规，解压、执行install脚本、启动taosd服务，三步走。我用的3.x版本，安装命令大致如下：

# 下载tar.gz包并解压（示例为3.x社区版） tar -zxvf TDengine-server-3.x.x-Linux-x64.tar.gz cd TDengine-server-3.x.x-Linux-x64 sudo ./install.sh # 启动服务并检查状态 sudo systemctl start taosd sudo systemctl status taosd

Windows环境能不能装？能装，但有几个坑必须提前规避。

第一，安装路径绝不能有中文和空格，否则服务能启动但建库时报错非常诡异；第二，Windows下默认不会自动注册成系统服务，需要手动进到安装目录执行taosd.exe -S来注册；第三，防火墙入站规则必须放行TCP 6030端口，否则客户端连不上，这个坑我调试了大半天才定位到。

装好后先用taos命令行客户端敲一句最简单的命令验证连通性：

SELECT server_version();

能返回版本号，说明服务端正常。到这里，TDengine的服务端部署就算跑通了。

3.2 库表设计：超级表就是为千表万表而生的

TDengine建库建表之前，一定要想清楚两个东西：采集频率和数据保留周期。采集频率决定了写入吞吐和分块参数，保留周期决定了存储空间。

我用的建库SQL是这样的：

CREATE DATABASE water_meter VGROUPS 16 BUFFER 256 CACHEMODEL 'both' DURATION 30d PRECISION 'ms';

几个参数说明一下。VGROUPS是虚拟存储组数量，可以理解为数据分片的数量，普通场景设成CPU核数或略高即可，后期也可以扩；DURATION 30d意思是一个数据分块覆盖30天的数据，分块越大查询时定位粒度越粗，但我测下来30天在读写性能和元数据开销之间比较平衡；PRECISION 'ms'是把时间精度设为毫秒，注意这里必须在建库时指定，后面没法改。

然后是超级表，我用下面的语句定义了一块水表的通用模板：

CREATE STABLE water_meter.meters ( ts TIMESTAMP, current_reading DOUBLE, flow_rate DOUBLE, pressure DOUBLE, status TINYINT ) TAGS ( meter_id BINARY(32), district BINARY(16), community BINARY(32), owner BINARY(64) );

这里字段按需设计：current_reading是水表累计读数，flow_rate是瞬时流量，pressure是管网压力，status是仪表状态码。标签字段meter_id、district、community、owner分别对应表号、分区、小区、户主，全部设计成静态属性，既方便按维度筛选，又避免了每条数据重复存储这些信息带来的额外开销。

子表不需要手工逐张创建，写入时用USING关键字自动建表即可：

INSERT INTO water_meter.d_1001 USING water_meter.meters TAGS ( 'M-1001', '城东片区', '锦绣花园', '张某某' ) VALUES ( NOW, 10086.25, 0.35, 0.28, 0 );

3.3 数据链路打通：从采集网关到TDengine的实时写入

建好库表之后，真实业务数据怎么进来？智能水表到TDengine之间的链路，我这边搭的是这样一套结构：

• 智能水表通过NB-IoT或者RS-485总线，把数据上报到区域采集网关/集中器；
• 采集网关通过MQTT协议，把解析好的抄表数据推给IoT平台或者规则引擎；
• 规则引擎做数据清洗，比如去重、设备状态判断、时间戳规整，然后写入TDengine。

如果你不想引入太多中间件，也有更轻量的做法。TDengine官方提供了taosAdapter组件，它能把MQTT消息直接转发入库，不需要自己写消费程序。不过我对数据质量要求比较严，所以中间还是加了一层用Python写的清洗服务，核心逻辑就是判断采集时间戳是否乱序、读数是否异常回跳、压力值是否越界，符合规则才入库。

写入这块，TDengine支持标准的批量INSERT语法，实测下来吞吐非常可观。多值批量插入的效率比单条插入高得多，建议按批次（比如每200条一批）写入：

INSERT INTO water_meter.d_1001 USING water_meter.meters TAGS ('M-1001','城东片区','锦绣花园','张某某') VALUES (NOW, 10086.25, 0.35, 0.28, 0), (NOW + 1s, 10086.30, 0.31, 0.29, 0), (NOW + 2s, 10086.38, 0.42, 0.30, 0), ...;

如果偶尔需要补录历史数据，比如网络断了一天，补传昨天的数据，也没问题。TDengine对乱序数据有专门的last_row机制，可以保证同一张子表内的同一时间戳只保留最后一条写入的记录，补录不会造成重复脏数据。

3.4 几个日常查询场景的SQL写法

存储做完了，最终要落到业务上。我这边用得最多的几个查询场景，写出来给大家参考。

第一个：某小区今日总用水量。

SELECT SUM(current_reading - lag_current_reading) FROM ( SELECT FIRST(current_reading) lag_current_reading, LAST(current_reading) current_reading FROM water_meter.meters WHERE district = '城东片区' AND ts >= NOW - 1d PARTITION BY meter_id );

这个SQL利用窗口函数和分区聚合，先算出每块表当日首末读数差，再汇总成小区总用水量，秒级返回。换成MySQL，这个查询几乎不可能在合理时间内跑完。

第二个：某户过去30天的日用水曲线。

SELECT _wstart AS day, diff(current_reading) AS daily_usage FROM water_meter.meters WHERE meter_id = 'M-1001' AND ts >= NOW - 30d PARTITION BY meter_id INTERVAL(1d);

diff()函数是TDengine的窗口内差值函数，INTERVAL(1d)按天切片，一次查询直接得到30天的逐日用度。漏损检测也在这个基础上做：把每天凌晨两点到四点的最小流量单独拉出来看，如果持续高于某个阈值，基本就能锁定该表背后存在暗漏或者用户异常用水。

第三个：综合状态巡检，按片区统计各表状态码分布。

SELECT district, status, COUNT(*) FROM water_meter.meters WHERE ts >= NOW - 1d PARTITION BY district, status;

标签字段直接参与分区聚合，效果非常直观，一张巡检大屏的数据就是从这个查询出的。

4. 踩坑实录：license expired 与安装部署中的隐形坑

4.1 internal error: license expired 的完整排查链路

这个报错应该是TDengine用户群里出现频率最高的问题之一了，我这边项目上线第三个月，开发环境的taosd实例突然就开始刷这条错：打任何SQL都返回internal error，服务端日志明确的写着一行license expired。

排查链路是这样的。先别慌，也别急着重装。第一步，看服务端日志，定位是哪个文件报的、报的是什么类型的授权问题。日志路径在/var/log/taos/taosd.log，搜license关键字就能看到过期时间点。

第二步，检查系统时间。tdengine的授权校验和系统时间强绑定，如果服务器挂了很长时间或者NTP同步有问题，可能导致时间超前，系统认为是授权过期。执行date看时间是否准确，如果不准先同步NTP再重启taosd。

第三步，确认装的是什么版本。这里有个很容易踩的坑：官网默认下载的可能是带试用授权的企业版安装包，这种包内置的授权一般只有一年，到期后就会报license expired。社区版是Apache 2.0协议开源、完全免费的，不存在授权过期问题。所以如果你用的是官方试用版装的生产环境，建议直接换成社区版安装包，重新安装并迁移数据。

第四步，也是很多人的盲区，检查Docker镜像。用Docker方式跑TDengine时，部分镜像默认带有试用授权，如果拉的是最新版且没加TAOS_LICENSE环境变量，用完周期就报错。解决方案是显式挂载社区版授权文件或者换用官方标注了community的镜像。

最后我的解决办法：卸载开发环境的试用版，下载社区版tar包重装，同时把taos.cfg里的licensePath配置项指向社区版授权路径，重启后问题彻底消失。生产环境从一开始就用社区版，到现在一年多没有遇到过license问题。

4.2 安装部署中几个容易被忽略的细节

安装层面的坑其实远比想象中多，这里我把自己踩过的或者帮别人排查过的总结一下。

第一个是文件描述符限制。TDengine默认会打开大量文件句柄，特别在超级表子表数量动辄十万百万的情况下。如果系统ulimit -n设置的是默认的1024，启动一段时间就会出现无法建立新连接、写入超时的现象。建议在/etc/security/limits.conf里给taos用户把nofile设到65535以上，重启进程生效。

第二个是时区配置。水表上报数据如果包含本地时间，而服务器设置的是UTC时区，写入后查询会差8小时，做日结报表时非常容易出乌龙。我的建议是统一在采集层把时间转换为北京时间，或者保持设备按UTC上报，但应用侧连接时显式设置时区。TDengine客户端连接参数支持timezone设置，服务端时区在taos.cfg里配timezone。

第三个是数据目录磁盘空间和SSD选型。TDengine的数据文件是顺序写为主，使用机械硬盘也能跑，但查询性能会明显受限于随机读。有条件的话，热数据一定要放SSD。TDengine 3.x支持分级存储，可以把30天前的历史数据自动迁移到HDD或者S3对象存储，配套这种能力，存储介质可以组合规划，节省不少成本。

第四个特别容易被忽略的是数据目录的inode数量。TDengine每个数据文件分块后会产生大量小文件，如果文件系统inode耗尽，即使磁盘还有空间，也会报磁盘写入错误。给数据目录单独分区，并选xfs或ext4格式，保险起见预留足够的inode。

4.3 数据安全与备份：时序库同样不能裸奔

很多项目上了时序库以后就把备份这回事给忘了，觉得写入性能这么好、数据一直在本地文件里，应该稳如磐石。但其实时序数据同样面临磁盘故障、误删除等风险。我这边做了三件事，供参考：

• 使用官方提供的taosdump工具做逻辑备份，每天晚上定时导出增量数据到独立备份服务器；
• 对TDengine的数据目录做文件级快照（比如LVM快照或云磁盘快照），用于快速灾难恢复；
• 关键业务数据（比如月结账单表）会同步一份摘要到MySQL，作为审计和财务对账的“底账”。

备份耗时和数据量成正比，我这边全量大约40亿条记录，用taosdump导出大概需要四个小时，所以按周全量加每日增量的节奏来做。如果是中小规模项目，数据量不大，建议直接每天全量，省心很多。

5. 上线后的效果与维护经验

5.1 存储成本与查询性能的改善

刚才在表格里看到的那组对比，不是实验室数据，是真实系统跑出来的。换到TDengine之后，最直观的改变体现为三个数字：

• 磁盘占用从2.1TB降到不到200GB，节省超过90%；
• 核心日结SQL从十一分钟降到三秒以内，一线抄表员在手机上就能直接查看小区用水汇总，而不是等隔天的Excel报表；
• 数据入库从原来的延迟两小时变成准实时，漏损告警可以在十五分钟以内触发。

存储介质这块，因为TDengine对机械硬盘的顺序读写也能保持不错性能，我把一年前的冷数据放在了大容量HDD上，SSD只放热数据。按当前数据增长速度估算，原来每年需要采购几块大容量企业级SSD，现在三五年内都不用动存储预算。这也是“数据存储介质演变”问题在水务场景里的实际解法：不是一味上昂贵介质，而是通过存储格式优化，让中低成本的介质也能扛住业务压力。

5.2 日常运维中的经验总结

长期跑下来，我总结了几个运维上的体会。

第一，超级表的标签值设计要预留扩展空间。刚开始我把小区和片区都写死成标签，后来新增了“供水所”这个行政维度，就只能通过修改标签值来做，老数据的标签是历史值，无法体现新维度。如果你也遇到类似问题，建议在标签里预留一到两个扩展字段，比如extra1、extra2，先留空，后续需要时再填充。

第二，采集频率调整要权衡存储与场景价值。水司容易被“更高频更实时”的口号带偏，把抄表频率从十五分钟提到一分钟，数据量直接翻十五倍，存储成本和查询开销都会上来。我的经验是先按业务目标倒推频率：做漏损分析用十五分钟粒度足够，做压力波动分析用到五分钟，只有做水力模型校核时才需要一分钟以内的数据。大部分水司把频率设在五到十五分钟之间，成本和价值最均衡。

第三，接入层要做好设备和数据质量元数据管理。TDengine存储的是“会说话的数据”，但前提是数据本身得干净。我在采集服务里维护了一个设备台账表，记录每只水表的安装日期、通信模块型号、上报频率、最近在线时间。一旦某块表连续几个周期没有上报，数据质量监控任务就会发出告警，而不是让它在TDengine里留下一个永远沉默的子表。

第四，版本升级不要追新，但也不能长期停在老版本。TDengine迭代速度确实快，社区版新版本会持续修复bug和优化性能。我的习惯是每次升级前先在测试环境跑一遍全量查询脚本和写入压测，观察三天无异常再上生产。小版本升级顺手就做了，跨大版本升级一定走完整的迁移验证流程。

5.3 这套方案还能怎么扩展

TDengine在水务项目里能干的远不止远程抄表存储。目前我这边已经在规划或已经落地的扩展方向有这几个：

把DMA分区计量的压力、流量数据统一并入TDengine，和抄表数据放在同一个库里。过去压力流量数据在另一个实时数据库里，两个系统对账非常费劲，合并后一套SQL就能把夜间最小流量、压力波动和水表用量关联分析，漏损定位的效率提高了很多。

把水质监测数据（浊度、余氯、pH值）也纳入这套存储，时序模型完全匹配，而且水质数据量比抄表数据小得多，对现有集群几乎无压力。

还有就是把告警规则引擎直接跑在TDengine的连续查询上，比如定时执行漏损检测SQL，结果写入一张告警结果表，再由业务系统读取推送。这样省掉了一套独立流处理框架，运维成本明显降低。

最后再分享一点个人体会

如果让我对正在做智慧水务选型的人说一句最实在的建议，那就是不要纠结于“哪个数据库最牛”，而是要选那个让业务数据模型最自然的存储。远程抄表数据的本质就是时序数据，时序数据就该用时序数据库来承接。TDengine不是唯一选项，但它的超级表模型、列式压缩存储和极低的运维门槛，在水务这种IT团队规模普遍不大的行业里，确实是一个非常务实的选择。

我踩过最深的坑，就是一开始按惯性思维用关系型数据库硬扛海量时序数据，白白浪费了几个月时间。换到TDengine以后，整个项目的推进速度完全不一样了。同样的数据、同样的服务器，存储少了、查询快了、运维省心了，这才是技术选型真正的意义。希望这篇经验总结能帮你在智慧水务的路上少走几步弯路。