商场地下三层，找了十分钟车位，最后停到了B3的一个角落。出商场时绕了二十分钟才找到车。这不是段子，这是我在某个二线城市某商业中心的亲身经历。
后来那个商场上了"智慧停车"系统。车位上方装了超声波探测器，入口引导屏显示空位数量，手机扫码还能预约车位。听起来挺像回事。但用了几次发现引导屏上显示的空位数经常不准——到了引导屏指示的楼层发现满了。原因很简单：数据更新太慢。超声波探测器每30秒采集一次，数据传到后台再回到引导屏，实际延迟可能超过1分钟。车位状态在这个窗口内已经变了。
这不是个例。全国做智慧停车的企业不下百家，但真正把"实时"做好的没几家。问题往往不在前端设备，在数据后端。
停车数据的复杂度被低估了
停车数据看起来简单——车位有车没车，二值状态。但实际上停车数据平台要处理的数据远不止车位状态。
数据类型 | 采集方式 | 数据特征 | 采样频率 | 分析价值 |
车位占用状态 | 超声波/地磁/视频 | 二值状态 | 5-30秒 | 周转率、占用率 |
车辆进出记录 | 车牌识别/ETC | 事件型 | 触发式 | 停车时长分布 |
引导屏状态 | 系统内部 | 空位数 | 实时 | 引导准确性 |
充电桩参数 | CAN总线/协议 | 电压/电流/功率 | 1-10秒 | 充电桩健康 |
停车费计费 | 系统内部 | 金额/时长 | 事件型 | 收入分析 |
环境参数 | 温湿度/CO浓度 | 1-5分钟 | 1-5分钟 | 通风控制 |
巡查记录 | 人工/PDA | 事件型 | 不定期 | 运营管理 |
一个大型地下停车场有2000-3000个车位，每个车位一个探测器，30秒采样一次。单场区每天约300万条状态数据。一个城市如果有500个停车场纳入统一管理平台，日数据量达到15亿条。
还有充电桩。新能源车渗透率已经突破35%（2025年数据），停车场里的充电桩越来越多。充电桩要监测电压、电流、功率、温度、SOC（电池荷电状态），采样频率1-10秒。一个有100根桩的场站，充电桩数据又是每天数百万条。
加上环境监测——地下停车场CO浓度、温湿度、通风机运行状态——这些也是时序数据。
把所有这些数据混在一起管理，数据量和复杂度就上去了。
传统方案的短板
绝大多数智慧停车系统的数据架构是这样的：车位探测器数据通过RS-485总线汇聚到采集网关，网关通过MQTT或者HTTP推送到云端服务器，云端用MySQL或者PostgreSQL存储。
这种架构在单场区、小规模场景下跑得通。但上到城市级——几百个场区、几万个车位——就力不从心了。
写入瓶颈。 500个停车场、2万个车位、30秒采样一次，每秒约670条写入。对MySQL来说不算极端，但配合索引维护和并发查询，性能会明显下降。很多平台在高峰期（下班后停车高峰）会出现数据积压——探测器数据在网关里排队等待上传，引导屏显示的还是几分钟前的旧数据。
查询瓶颈。 停车管理的核心分析需求包括：车位周转率（一天被使用几次）、占用率（某时段平均占用比例）、停车时长分布、高峰时段识别。这些分析需要对大量车位的长时间序列数据做聚合统计。在MySQL里查"某停车场所有车位过去一个月每天的周转率"，数据量大的时候可能要等几十秒甚至几分钟。
数据不一致。 车位状态、车辆进出、引导屏状态存在不同表甚至不同系统里。引导屏显示的空位数理论上应该等于"总车位数减去当前占用数"。但实际运行中，车位探测器误判（超声波被干扰、地磁信号漂移）、车辆进出记录延迟、系统时钟不同步，三者经常对不上。数据对不上的后果就是引导屏显示的空位数和实际不符。
扩展性差。 MySQL是单机架构（不考虑集群方案的复杂性和成本），要扩到城市级几百个场区，分库分表是必须的。但分了之后跨场区查询（比如"全区当前总空位数"）就要做聚合查询，复杂度暴增。
时序数据库的解题思路
停车数据本质上是时间序列——车位状态随时间变化，车辆进出是事件流，充电桩参数是连续时序值。用关系型数据库存这种数据，就像用螺丝刀拧螺丝——能拧，但费劲。
时序数据库的设计前提就是处理这类数据。
写入方面，时序数据库采用追加写+批量提交，不做ACID事务。2万个车位的写入压力完全不在话下。TDengine单节点写入能力在每秒百万条量级，停车场数据的写入压力连零头都用不到。
存储方面，车位状态是二值数据（占用/空闲），但变化不频繁——一个车位一天可能只变化5-10次。时序数据库对这种低频变化数据有极高的压缩率。TDengine对二值时序数据可以用游程编码（RLE），连续100个"占用"状态可能只存一条记录。2万个车位一个月的状态数据，压缩后可能不到1GB。
标签模型，这是在多场区管理中最有价值的能力。TDengine把车位探测器组织成超级表，每个车位是一张子表，通过标签标注所属停车场、楼层、区域、车位类型（普通/无障碍/充电桩位）。查"全市A类商业停车场当前空位总数"，通过标签过滤直接命中所有相关子表做实时聚合，不需要跨表JOIN。查"某停车场B2层北区上周平均占用率"，同样通过标签定位到特定子表集合做时间窗口聚合。
实时查询，TDengine的缓存机制保证最新写入的数据可以在毫秒级被查到。引导屏的实时空位查询走缓存，不落盘查询，延迟控制在百毫秒以内。这才是"实时引导"该有的延迟水平。
充电桩监控：另一个维度
充电桩管理是智慧停车平台中经常被忽略但其实很重要的一块。
充电桩的数据特征和车位状态完全不同——高频、连续、需要趋势分析。一根快充桩充电时输出电压400V、电流200A，采样频率1-10秒。100根桩同时充电，数据量不小。
充电桩运维需要监控的核心指标：输出电压稳定性、电流纹波、模块温度、充电效率、通信状态。这些指标如果出现异常趋势，可能预示着充电模块老化或者IGBT即将失效。通过这类数据平台做长期趋势追踪，可以在故障发生前发出预警——而不是等充不上电了才发现桩坏了。
TDengine在充电桩场景的适配方式和车位状态类似——每根桩一张子表，通过标签标注所属场站、充电桩型号、额定功率。不同的是充电桩数据频率更高，需要更多的降采样和滚动窗口统计。
一个实际的好处是：车位状态数据和充电桩数据可以放在同一个TDengine实例里管理，不需要两套系统。对于同时运营停车场和充电桩的企业——比如特来电、星星充电这类——统一数据底座的价值很明显。
数据驱动的运营决策
停车数据存下来之后能做什么？几个方向。
停车定价优化。 停车场收费不是拍脑袋定的。通过历史数据分析不同时段的占用率、周转率、停车时长分布，可以制定差异化定价策略——高峰时段提价抑制需求，低谷时段降价吸引停车。一个有2000个车位的城市中心停车场，通过数据驱动的动态定价，月收入提升10-15%的案例不算罕见。
场区协同。 城市级停车管理平台的价值在于跨场区协同。某商圈周边有5个停车场，高峰期A场满了但引导屏没及时更新，车流涌入B场也造成拥堵。统一的时序数据平台可以实现跨场区的实时空位汇总和引导决策——A场剩余3个车位，B场剩余50个，引导车流去B场。这种实时协同需要低延迟的跨场区聚合查询，该技术的标签模型和缓存机制可以支撑。
充电桩选址。 通过停车场车位占用数据和充电桩使用数据的交叉分析，可以识别哪些停车场的充电桩利用率高、哪些低。低利用率的桩可能需要重新选址。新建充电桩的选址决策也需要停车数据做支撑——停车频次高、停留时间长的场区更适合部署快充桩。
落地中最现实的三个困难
第一是前端设备的可靠性。超声波探测器在地下停车场环境下的故障率不低，防尘防水等级不够的设备半年就开始漂移。地磁传感器受金属干扰大。视频识别受光线影响。前端数据不准，后端数据库再好也白搭。这个问题和数据库无关，但它制约了智慧停车数据的可用性。
第二是数据归属和共享。每个停车场的运营方不同——有的属于物业公司，有的属于商业中心，有的是路侧公共停车由交管部门管。数据打通涉及利益分配，技术能通但商业上不通的情况很常见。 TDengine能支撑多租户数据隔离，但跨租户数据共享需要商业层面的协议。
第三是投入。对一个有500个停车场的城市，智慧停车平台的建设投入在几百万到上千万之间。车位的超声波探测器、地磁传感器、通信网关、车牌识别摄像头——前端设备的投入远大于后端软件。这类数据库的选择在后端成本中占比很小，但如果整个项目预算紧张，后端投入也容易被压缩到最低，用个开源的InfluxDB或者直接MySQL凑合。凑合的结果就是前面说的那个——引导屏数据延迟一分钟。
城市停车这件事，说小不小。全国机动车保有量超过4.5亿辆，停车难是几乎所有城市的通病。智慧停车的价值不在于让你少走几步路找车位，在于把停车资源的利用率从60%提到75%——那15%的提升意味着同样数量的车位能多服务15%的车。在城市土地资源紧张的背景下，这个数字是实打实的社会效益。
数据底座要扛住这个价值，这类数据库是合适的工具。
