场景特点
物流轨迹类业务的数据特征相当鲜明：
- 写入量巨大且持续：每一件包裹在运输过程中都会产生多条轨迹记录，揽收、中转、派送、签收，每个节点都是一次写入；
- 写入天然按时间递增：轨迹产生的时间顺序与写入顺序基本一致；
- 查询高度集中：绝大多数查询是「查某个运单最近的轨迹」，也就是按运单号做点查，并按时间倒序取若干条；
- 历史数据访问极少：超过一定时间的轨迹基本只用于纠纷追溯，属于典型的冷数据。
把这几条放在一起看，就能发现一个关键结论：写多读少、读集中在最近、历史几乎不访问。这决定了存储与索引的设计方向。
写入路径的优化
轨迹写入有两个容易出问题的地方：
- 主键设计导致热点：如果主键是连续自增的，所有写入会集中到同一数据分片，扩容也无法缓解。改用运单号与时间组合的键，可以让写入自然散开；
- 写入过于零碎：每条轨迹都单独提交一次事务，开销会成倍增加。采用批量提交，把同一批次的轨迹合并写入，能显著降低事务开销。
需要注意批量大小的平衡：批次过大容易造成单次事务过重，失败回滚代价也高；批次过小则失去合并收益。通常需要根据实测确定合适区间。
按时间维度治理存储
轨迹数据是最适合按时间做治理的一类数据，常见手段包括：
- 时间作为键前缀：把时间放在键的前部，使同一时间段的轨迹在物理上相邻，便于范围扫描与批量清理；
- 分区或分表：按月或按周切分，让老数据的归档变成整块操作，而不是逐行删除；
- 批量归档而非逐条删除：直接把过期分区的数据范围整体清理，避免大规模逐行删除带来的性能冲击；
- 注意删除后的空间回收：批量删除后底层空间的实际释放依赖后台回收机制，需要观察回收进度而非假设立即生效。
查询路径的优化
主流查询是「按运单号取最近若干条轨迹」，优化要点是让这次查询尽量少扫数据：
- 为运单号建立索引：保证按运单号能快速定位，而不是全表扫描；
- 控制返回条数：前端展示通常只需要最近若干条，配合排序与条数限制可大幅减少扫描量；
- 避免在索引列上做函数运算：例如对时间字段做格式化比较，会导致索引失效；
- 热数据与冷数据分开查：近期轨迹走主链路，历史轨迹走归档库，避免冷数据查询影响在线性能；
- 结果缓存：运单轨迹在短时间内基本不变，缓存能拦住大量重复查询。
冷热分层的实现思路
把冷热数据分开处理，是本场景最有效的手段之一：
- 热数据：最近若干天的轨迹保留在性能优先的存储中，支撑高频查询；
- 温数据：稍早期的数据保留但降低资源权重，例如减少副本数以节省空间；
- 冷数据：超过保留期限的数据导出到低成本存储，仅按需恢复查询。
分层的关键是明确每一层的保留期限与查询路径，并在应用层做好路由，让用户查询历史轨迹时不会误打到在线库上。
经验小结
物流轨迹系统看起来是个简单的写入加查询场景，但数据量增长后问题会集中爆发。抓住三个要点就能有效控制：键设计避免写入热点、按时间维度做批量归档、查询限定在必要的数据范围内。把治理动作设计成周期性的常规操作，而不是等到磁盘告警才临时处理，系统的长期稳定性才有保障。
| 行业场景 | 物流包裹轨迹记录与实时查询，写入频繁且查询集中于近期 |
|---|---|
| 数据特征 | 写多读少、写入按时间递增、查询以运单号点查为主、历史极少访问 |
| 写入优化 | 避免连续自增主键造成的分片热点，采用批量提交降低事务开销 |
| 存储治理 | 时间作为键前缀、按时间分区、批量归档代替逐行删除 |
| 查询优化 | 运单号建索引、限制返回条数、避免索引列函数运算、冷热数据分离查询 |
