一个三线城市，城区常住人口80万。环卫处管着城区6200个垃圾桶、34辆垃圾清运车、18座公共厕所。2023年这城市上了一套”智慧环卫”系统，预算87万。领导的要求不高：让垃圾车别空跑。
空跑是什么意思？垃圾车按固定路线每天跑一遍，不管桶满没满。有些桶在商业区，午饭时间就满了；有些在居民区，三天也装不满半桶。按固定路线跑的结果就是——满的桶溢出来了没人收，空的桶车去跑了一趟白费油。
固定路线跑了十年，谁都觉得不对，但没人知道怎么改。因为没人知道哪个桶什么时候满。
智慧环卫系统要做的事，说穿了就是知道每个桶什么时候满，然后让车去收。听起来简单，做起来涉及一整套数据链路：垃圾桶装满溢传感器→数据传到平台→平台算出需要收运的桶→规划最优路线→派车。
这个链路里最不起眼但最关键的一环是数据存储和管理。6200个传感器，每个5-15分钟上报一次状态，加上34辆车的GPS和作业状态、18座公厕的环境参数。不算多，但也不是小数目。用什么存？存在哪？怎么查？
环卫数据有多杂
智慧环卫的数据来源比大多数人想的杂。垃圾桶满溢、环卫车轨迹、公厕环境，三件事听起来风马牛不相及，但确实需要在同一套系统里管理。
数据类型 | 采集设备 | 数据特征 | 采样频率 | 单日数据量 |
垃圾桶满溢 | 超声波/红外测距 | 满溢百分比 | 5-15分钟 | 600-1800条/桶 |
垃圾桶温度 | 温度传感器 | 环境温度 | 15-30分钟 | 48-96条/桶 |
环卫车GPS | 北斗/GPS模块 | 经纬度/速度 | 3-10秒 | 8640-28800条/车 |
环卫车油耗 | 油位传感器 | 油量百分比 | 30-60秒 | 1440-2880条/车 |
环卫车作业状态 | OBD/专用设备 | 作业/空转/行驶 | 3-10秒 | 8640-28800条/车 |
公厕温湿度 | 温湿度传感器 | 环境参数 | 5-15分钟 | 96-288条/厕 |
公厕氨气 | 气体传感器 | NH3浓度ppm | 5-15分钟 | 96-288条/厕 |
公厕人流量 | 红外计数器 | 累计人数 | 1-5分钟 | 288-1440条/厕 |
6200个垃圾桶，假设平均10分钟上报一次，每天约89万条。34辆车GPS每5秒上报一次，每天约59万条。18座公厕各项参数加起来每天约2万条。总量约150万条/天。
不多。对时序数据库来说这个量级很轻松。但问题不在于量，在于数据类型杂——三种完全不同特征的传感器数据混在一起，要统一管理还要做交叉分析（比如”某个垃圾桶满溢频率和该区域公厕人流量有没有相关性”——商业区的垃圾桶满溢和公厕使用量可能正相关）。
传统方案通常的做法是三套系统各管各的——垃圾桶数据在物联网平台里，车辆数据在GPS调度平台里，公厕数据在环境监控平台里。三个平台三个供应商，数据格式三种，查个跨系统数据还得导Excel。
为什么传统方案不好使
倒不是说传统方案完全不行。这么小的数据量，MySQL也能存。能存不代表能用好。
查询性能。 MySQL存150万条/天，一个月就是4500万条。查”过去一个月商业区A片区的所有垃圾桶满溢时间分布”——需要按区域过滤6200个桶中的子集，再按时间范围聚合。如果表结构没设计好（没按区域分区、没加合适索引），这个查询可能要等一分钟。如果同时有3-4个用户在做不同的分析查询，数据库就卡了。
数据关联。 最典型的分析需求是路线优化。要算最优收运路线，需要同时知道：哪些桶满了（垃圾桶数据），车在什么位置（GPS数据），车还剩多少油（油耗数据），当前在做什么（作业状态数据）。这四个数据源如果在不同系统里，做联合查询简直要命。就算都在MySQL里，四张表JOIN起来性能也很差。
实时性。 垃圾桶满了到一定程度需要触发收运调度。这个触发需要实时监控满溢数据——当某个区域的桶满溢率超过阈值时，系统应该主动提示调度员安排车辆。传统轮询数据库的方式延迟大，一个5分钟采一次的数据，最坏情况延迟5分钟才知道桶满了。在商业区午间高峰，5分钟可能垃圾桶就溢出来了。
多区域管理。 如果一个环卫处管多个片区（老城区、新城区、工业园区），每个片区的垃圾产生规律不同。按片区做差异化调度需要标签化管理——每个垃圾桶标注所属片区、道路、类型（可回收/厨余/其他）。MySQL虽然可以通过外键表做关联，但查询时需要JOIN，性能不理想。
时序数据库的解题方式
150万条/天的数据量对TDengine来说完全不构成压力。但时序数据库在环卫场景的价值不在”存得下”——MySQL也能存。价值在于存的方式和查的方式。
标签模型适配多区域。 TDengine把垃圾桶传感器组织成超级表，每个桶是子表。标签可以包括：片区编码、道路名称、桶类型、桶容量、GPS坐标。查”老城区所有厨余垃圾桶今天满溢超过3次的有几个”——通过标签过滤加时间窗口聚合，几毫秒到几十毫秒就返回了。MySQL做同样的查询需要扫全表或者做多表JOIN。
GPS轨迹高效存储。 环卫车GPS每5秒上报一次位置，一天约17280条/车。34辆车每天约59万条。GPS轨迹数据的特点是——经纬度变化有规律（车辆在固定路线上行驶），相邻两个点差异小。时序数据库对GPS数据的压缩效率比关系型数据库高很多。
跨数据类型联合查询。 在TDengine里，垃圾桶、环卫车、公厕三类数据可以放在同一个数据库的不同超级表里。通过标签关联——比如某个垃圾桶附近最近的公厕——可以通过空间标签（如片区+道路）做关联，不需要跨系统导数据。路线优化算法可以直接从TDengine拉取所有需要的数据：满溢桶列表+车辆位置+剩余油量+作业状态，一条SQL拿全。
实时数据订阅。 当垃圾桶满溢率超过设定阈值时，TDengine的数据订阅机制可以实时推送给调度系统。延迟在秒级。比轮询数据库的方式实时性强得多。
垃圾收运调度优化
这是智慧环卫最核心的业务价值。拆解一下技术逻辑。
满溢预测。 垃圾桶满溢不是均匀的。商业区工作日午间高发，居民区周末高发。通过历史满溢数据的时序分析，可以建立每个桶的满溢模式——按小时统计一周内满溢频率分布，识别高峰时段。当某桶的实时满溢百分比接近阈值且处于历史高峰时段时，系统提前预警——不等桶满了再调度。
这个分析需要至少两周到一个月的历史满溢数据。TDengine的连续查询可以自动按小时聚合每个桶的满溢统计数据，生成模式表。
路线优化。 系统识别出当前需要收运的桶列表后，结合车辆位置和作业状态，用车辆路径优化算法（VRP）计算最优路线。VRP需要的输入数据：桶的GPS坐标（标签里存了）、车辆当前位置（实时GPS数据）、车辆剩余容量、预计收运时间。这些数据全部在TDengine里，路线优化算法直接查。
路线优化的效果用数据说话。前文那个三线城市的智慧环卫系统上线后，日均清运车次从34辆次减少到27辆次（部分满溢率低的区域改为隔日收运），单车日行驶里程从56公里降到41公里。油耗降低约25%。空跑率从40%降到12%。
异常识别。 如果某个垃圾桶连续几天满溢频率突然下降，可能不是垃圾少了，而是桶坏了或者传感器故障。如果某个区域满溢频率突然上升，可能是周边有新商户入驻或者有活动。时序数据库可以做异常检测——基于历史均值加减标准差做上下限，超限触发提示。
公厕环境监控
公厕这块经常被忽略，但其实是城市管理的面子工程。
18座公厕，每座装了温湿度、氨气浓度、人流量传感器。数据量不大，但分析价值不低。
氨气浓度是公厕环境卫生的核心指标。GB/T 17217规定了城市公共厕所环境卫生标准，氨气浓度不超过0.3mg/m³（约0.4ppm）。通过氨气传感器实时监测，浓度超标时自动启动排风系统——不是定时开关，是按需启停。这个联动逻辑需要一个数据平台做中间层：传感器数据→平台→排风控制。
人流量数据也有价值。通过公厕人流量和垃圾桶满溢数据的交叉分析，可以间接评估某个区域的”活动密度”——人流量高+垃圾桶满溢快=高活动密度区域。这个信息对城市管理决策有参考价值——比如垃圾收运频次的区域差异化设定。
低成本才是关键
坦率讲，智慧环卫的技术含量不算高。垃圾桶传感器几十块一个，GPS模块也不贵。系统本身的硬件投入不大——6200个满溢传感器加上34辆车的车载设备加上18座公厕的环境传感器，硬件总投入可能就几十万。
真正决定项目成败的是数据平台的可持续性。如果用一套复杂的传统IT架构——Oracle数据库+中间件+定制开发软件——软件和运维成本可能比硬件还高。87万的预算，硬件去掉30万，软件和实施还剩57万。如果数据库选型选贵了，留给应用层开发的预算就紧张了。
TDengine在成本上的优势对这类中小城市项目是实打实的。开源版免费，企业版按需付费，部署运维简单——不需要专职DBA。一个三线城市环卫处的IT能力有限，搞不定一套需要专业DBA维护的Oracle系统。TDengine的运维门槛低得多，SQL接口兼容MySQL协议，会写SQL的运维人员就能上手。
这不是说TDengine比Oracle强——它们定位不同。Oracle擅长事务处理和复杂关系数据管理。TDengine擅长时序数据的高效存储和查询。环卫数据是时序数据，选这种数据库是顺理成章的事。
降低智慧城市项目的门槛，让更多中小城市用得起、用得好，这才是这类数据库在这个场景中最大的价值。不是每个城市都有深圳的预算和人才。80万人口的三线城市也需要智慧环卫，也需要数据驱动管理，但预算就那么多。
把钱花在刀刃上。数据库选对了，预算就能多留给应用层。选错了，光数据库运维就把预算吃完了。
这道理不复杂。但很多地方还是踩了坑。
