浙江好多物联主营智慧停车业务，覆盖车辆入场、计费、出场的完整流程。主平台跑在 PolarDB 商业版上，数据量近 2TB，核心三表每年新增约 2.4 亿条。大表到 8000 万行后查询严重变慢，跨停车场 join 操作困难，开源 PolarDB 社区不活跃且存在内存泄漏。团队评估了 TiDB、ClickHouse和其他分布式数据库后，先在区级平台用 TiDB v8.5.2 跑了一年多，慢 SQL 数量从满屏降到每天 46 条。
停车业务有个硬性约束：24 小时不能停。数据库一旦崩了，车主进不了场、出不了场，影响是实时的。好多物联数据库负责人奉起刚说：“一个平台一年有几次崩溃，客户是接受不了的。”
旧数据库的瓶颈：跑到 8000 万行，查不动了
主平台的大表主要是入场表、出场表和缴费表。入场表每月新增 900 多万条，每年约 1.09 亿条，核心三表每年合计新增约 2.4 亿条。
大表到 8000 万行，问题开始集中暴露：查询速度明显变慢，满屏慢 SQL。这里头有研发索引设计的问题，但浙江好多物联原本使用的数据库本身也有状况——多张大表做 join 查询时，有一定几率某些字段查不出来。“这就非常尴尬，非常影响客户进行对账。”
智慧停车平台上云之后，一个集团账号下面可能有多个停车场，跨停车场 join 操作非常慢。加上之前使用的数据库商业版和开源版差距大——区级平台一开始想用这个数据库的开源版本做私有化部署，结果发现开源版更新频率极低，存在内存泄漏，社区也不活跃，遇到问题很难解决。
“作为停车的业务来说，数据库不能满足当下的情况，我们需要考虑 3 到 5 年的场景。下面的停车场越来越多，一旦崩溃，整个平台就会崩溃。”
选型：试过才知道差距在哪
好多物联的选型思路是“实践是检验的核心标准”——不只是看纸面参数，而是调研了一些主流数据库并部署起来实际跑了一遍。
在好多物联团队的选型测试中，TiDB 在压缩能力、成本、在线交易（OLTP）与实时分析（OLAP）等维度的综合表现优于 Clickhouse 与其他分布式数据库。同时，TiDB 对 MySQL 的高度兼容性让业务几乎不用改代码，开源社区持续更新，遇到问题在 TiDB 社区论坛上问很快有回复。
“为什么我们敢上 TiDB？是因为前面有非常多龙头的企业，包括银行、物流、物联网大厂都已经用上了，已经帮我们验证过了。我们可以放心选择。”
奉起刚还提到最近正在关注平凯数据库云服务，平凯云 DB 的成本灵活可控，还能免去自己搭建集群的运维工作。
迁移：导出慢，导入快
区级平台迁到 TiDB，用的是 Dumping 导出加 Lightning 导入。奉起刚说了一个差异显著的细节：“从旧数据库导出数据速度非常慢，但是数据导到 TiDB 上非常快速丝滑。”
此次迁移也推动浙江好多物联团队优化了一批技术问题。之前研发会用 force index——因为原有数据库的查询没有命中预期的索引。迁移到 TiDB 后 force index 不再适用，团队借机规范了索引设计。Go 代码中的 First 或 Last 命令默认按 ID 排序，在分布式架构下也需要改为按时间排序。奉起刚说：“通过这一次换库，倒逼我们进行了一遍清理，代码就更干净了。”
TiDB 上线一年后：慢 SQL 从满屏到 46 条
在浙江好多物联智慧停车的区级平台已经在 TiDB 上跑了一年多，基本上没有任何问题。
带来的最直观变化是慢 SQL 大幅减少。迁移前满屏慢 SQL，迁移后最近一天之内只有 46 条，主要是一些 count 统计查询，而且跨车场 JOIN、集团聚合这些在用 TiDB 后一行 SQL 没改速度就提升了。
监控体系也实现了从无到有——以前“旧数据库挂掉之后都不知道发生了啥”，现在用 Grafana 加钉钉告警，数据库状态实时可见。团队还对告警做了分级：延迟类的小问题推小群，严重问题推正式群，避免噪声淹没信号。
运维也从被动变成了主动。TiDB 支持三节点混合部署，支持业务弹性扩展，“容量规划可以主动安排，如果后期区平台的数据不够，扩容也比较方便”。
更大的隐性收益是团队的精力释放。“对于停车来说，更多精力应该放在停车的业务上，而不是折腾数据库。数据库迁移到 TiDB 之后，我们就有更多精力放在 AI 智能体上应用上。”
下一步：主平台迁移和新场景上线
主平台目前还在旧数据库上，没有迁到 TiDB 的主要原因不是技术，是地域。“主平台服务器在张家口，后面随着平凯数据库云服务在张家口开区，会考虑把主平台迁移到 TiDB。”
区级平台的推广策略也在调整。后续“路边停车”、“城市级平台”等新项目将优先上线 TiDB，基于 TiDB 的水平扩展能力应对未来更大的停车数据、更多的设备、更复杂的计费。
浙江好多物联团队还在研发停车智能体，用 TiDB 作为数据底座，结合数据和业务规则做自动异常检测和决策支持。奉起刚也关注到了平凯 Loop：“我们也在关注平凯 Loop 能不能应用到停车的业务上来。”
物联网与智慧停车业务的选型建议
最后，针对不同业务场景，浙江好多物联的数据库选型建议是：如果是小项目，比如单停车场，MySQL 可能就够了。同时，平凯数据库敏捷模式也提供小数据规模下的单机运行与混合负载能力。如果是中大型 SaaS 平台推荐直接用 TiDB，后期水平扩展非常方便。而在分析密集型场景，TiDB HTAP 架构可以避免 OLTP 和 OLAP 的数据割裂，支持统一实时分析。
在智慧物联与停车行业，数据库稳，平台才稳，选型更多要考虑未来 3 到 5 年的数据增量。选对正确数据库，释放研发资源用在业务上，才能快速满足客户需求。