订单编号该递增，还是用 UUID？

单个数据库可以用序列或自增列协调分配数字；多个互不联系的生成者则需要约定各自范围，或使用适当的分布式生成方式。UUID 是一组一百二十八位标识格式，其中 v4 使用随机或伪随机位，通常不必为每次生成联系一个中央计数器。

“极难碰撞”和“数学上绝不碰撞”不是同一句话。随机源、实现错误和数据导入仍需要考虑，数据库唯一约束仍有价值。对一条重要写入，应明确遇到冲突怎样处理，而不是因为名字里有“唯一”，就取消最后一道数据约束。

RFC 9562 定义的 UUIDv7 在高位放入毫秒时间信息，并用其余部分承载随机数据或符合规则的补充字段。因此讨论“UUID 的插入顺序”时，要先问是哪一版，不能把 v4 的随机性套到所有 UUID 上。时间排序也不自动等于多个机器上的真实全局发生顺序。

假设甲先取得一个编号，却做了较长计算；乙后取得编号，先提交事务。按编号排出来，甲仍可能在乙前面，但提交顺序恰好相反。需要展示创建时间、支付时间或严格业务序号时，应明确记录相应事件，而不是指望一个主键回答所有时间问题。

在 MySQL 8.4 InnoDB 中，表的行数据通常按主键组织为聚簇索引，二级索引记录也携带主键。因此较长主键的空间成本可能出现在多个索引里。UUID 是一百二十八位，但把它存成二进制还是带连字符文本，数据库字段与编码也会影响实际占用。

递增与分散的键会让插入位置不同，但性能还取决于数据量、缓存、并发和存储结构。不能仅凭一个编号样例就宣布谁快十倍，更不能把 InnoDB 的结论原封不动搬到另一种数据库。评估时固定存储类型、索引数量和负载，再比较写入与查询成本。

递增也不代表没有缺号。PostgreSQL 17 文档明确说明，事务回滚等情况不会收回已领取的序列值，因此不能拿普通序列承诺连续无缺号。若业务确实要求编号连续，需要单独设计分配、作废和审计规则，并接受相应协调成本。

内部主键与给用户看的订单号可以分开设计：一个服务于存储关联，一个服务于输入、查找或业务规则。随机编号也不能代替权限检查，知道一个编号不意味着有权读取对应订单。最后把需求写成清单：谁生成、能否离线、怎样合并、如何排序、冲突怎么办，再选择符合它们的方案。