mysql可存快递物流状态，但需依量级与查询模式权衡：日增10万以下、查最新状态为主时适用；超百万轨迹点或复杂跨状态分析则易性能瓶颈。
快递物流状态该不该用 MySQL 存？
能存，但得看量级和查询模式。单日新增 10 万以下运单、查最新状态为主、不频繁做跨状态时间分析的场景，MySQL 完全够用；一旦要支持“查某省所有昨天从‘已揽收’变成‘派送中’的订单”，或者日增百万+轨迹点，就容易卡在索引膨胀、写入延迟和 JOIN 效率上。
常见错误现象：SELECT * FROM tracking_log WHERE order_id = ? ORDER BY create_time DESC LIMIT 1 在千万级表上变慢，不是因为没加索引，而是 order_id + create_time 复合索引没覆盖查询字段，导致回表严重。
- 务必让
order_id和create_time组成联合索引，且顺序为(order_id, create_time)（不是反过来） - 如果常查“某个时间范围内所有状态变更”，再加一个
(create_time, order_id)索引 - 避免在
status字段上单独建索引——离散度低，MySQL 很可能直接放弃走索引
一条物流记录该存哪些字段？
别一上来就堆 status、status_text、operator、location、remark……字段越多，行越宽，Buffer Pool 压力越大，批量写入时锁等待越明显。
核心字段只留四个：order_id、status、create_time、update_time。其余如操作人、网点、经纬度、图片 URL，全扔进 extra JSON 字段里（MySQL 5.7+ 支持 JSON 类型，带校验和索引能力）。
-
status用 tinyint 或 enum，别用 varchar —— 比如 1=已揽收，2=运输中，3=派送中，4=已签收 -
create_time必须是DATETIME(3)或TIMESTAMP(3)，精度到毫秒，避免同一秒多条状态冲突 - 不要在表里存“前一个状态”，状态流转逻辑应由应用控制，数据库只负责落库事实
怎么避免重复插入同一条状态？
上游系统重试、MQ 重复消费、前端连点两次提交，都会导致相同 order_id + 相同 status + 几乎同时间的状态被插两次。MySQL 本身不拒绝，但业务上这属于脏数据。
最稳的方式是加唯一约束：UNIQUE KEY uk_order_status_time (order_id, status, create_time)。注意：时间字段必须带毫秒精度，否则秒级时间在高并发下形同虚设。
- 如果业务允许“同一状态多次记录”（比如反复扫码确认），那就把
create_time换成create_time, operator_id组合去去重 - 别依赖应用层先
SELECT再INSERT—— 这种 check-then-act 在并发下必然漏判 - 冲突后捕获
1062 Duplicate entry错误，直接忽略或记录告警，别抛异常中断流程
历史状态要不要归档？
要，而且得主动归档，不能等 tracking_log 膨胀到 2GB 才想起这事。MySQL 单表超过千万行，即使索引良好，ALTER TABLE 加字段、改类型也会锁表数分钟，线上扛不住。
推荐按月分表：tracking_log_202408、tracking_log_202409……用 order_id 哈希或取模做路由，比按时间范围查更均匀。归档动作在凌晨低峰期跑，用 INSERT INTO ... SELECT + DELETE 分批处理，每批不超过 5000 行。
- 归档前确认下游报表、BI 工具是否还依赖老数据 —— 有些系统硬编码查了
tracking_log表名 - 不要用
mysqldump导出再导入归档表，大表下 IO 和锁开销太大 - 归档表的
create_time索引可以去掉，只保留order_id索引，毕竟归档后基本只按单号查
真正难的不是设计字段或建索引，是预判状态变更的节奏：比如大促期间“已揽收”到“运输中”平均耗时从 2 小时缩到 15 分钟，意味着同样运单量，轨迹点会多 8 倍。这种变化，光看当前 QPS 是看不出风险的。
