CREATE TABLE orders ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id BIGINT UNSIGNED NOT NULL, amount DECIMAL(10, 2) NOT NULL);

第一笔订单的 id 是 1。

第二笔是 2。

既然数据库已经自动生成了唯一 ID，能不能直接把它当成订单号展示给用户？

例如：

订单号：10001订单号：10002订单号：10003

技术上当然可以。

但在真实业务中，通常不建议把数据库自增 ID 直接当成对外订单号。

核心原因不是它不唯一，而是它太容易被猜到，而且会把数据库内部结构直接暴露给外部。

自增 ID 本来是做什么的？

自增 ID 最适合做数据库内部的主键。

它的优点很明显：

生成简单占用空间小比较和关联方便大体按递增顺序写入

订单明细表可以通过 order_id 关联订单表。

后台程序也可以通过主键快速查找一条记录。

这些都是数据库内部使用场景。

但订单号是一个业务编号。

它可能出现在订单详情页、支付记录、客服沟通、物流单据和外部接口中。

一个是内部数据标识。

一个是对外业务凭证。

它们都要求唯一，但职责并不相同。

自增订单号很容易被遍历

假设用户访问订单详情的地址是：

/orders/10001

如果下一个订单号大概率就是 10002，别人只需要不断修改地址里的数字，就能尝试访问其他订单。

当然，真正的安全问题不是用了自增 ID，而是接口没有校验订单归属。

无论订单号长什么样，服务端都必须确认：

当前登录用户是否有权查看这笔订单

不能因为订单号难猜，就省略权限校验。

但是，连续的自增 ID 会让批量猜测和遍历变得特别简单。随机性更高的业务订单号虽然不能代替鉴权，却可以减少这种低成本探测。

它还会暴露业务量

如果订单号每天都在连续增长，外部人员记录两个时间点的订单号，就可能粗略推测平台新增了多少订单。

例如：

上午订单号：120000晚上订单号：128000

即使中间存在取消、测试或其他数据，也足以让人估算系统的大致业务规模。

对于某些公司，这属于不希望公开的经营信息。

对外订单号加入日期、随机数或其他生成规则后，不再与数据库记录数保持明显的连续关系，就不容易被这样直接估算。

数据库一变，外部接口也跟着变

如果订单号就是表的自增主键，数据库内部调整可能会直接影响外部业务。

例如：

订单数据需要迁移到新库多个订单库同时生成订单历史数据需要合并系统拆分成多个服务测试数据与正式数据需要隔离

单库中的自增 ID 很容易生成。

但多个数据库节点各自自增时，如果没有额外规划，就可能出现冲突，或者需要设置不同的步长和起始值。

更麻烦的是，订单号一旦已经发给用户、支付平台或物流系统，就很难随意修改。

如果内部主键和业务订单号分开，数据库可以根据存储需要调整，外部业务编号也可以保持稳定。

这相当于在数据库结构和业务接口之间留了一层缓冲。

正确做法是什么？

常见做法是在订单表里同时保留两个字段：

CREATE TABLE orders ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, user_id BIGINT UNSIGNED NOT NULL, amount DECIMAL(10, 2) NOT NULL, UNIQUE KEY uk_order_no (order_no));

其中：

id用于数据库内部主键和表关联 order_no用于页面展示、业务查询和外部系统交互

order_no 必须建立唯一约束。

不能只依赖程序先查询“有没有重复”，因为并发情况下，两个请求可能同时判断为不存在。最终兜底的唯一性应该由数据库约束保证。

订单号应该怎么生成？

订单号没有唯一的标准格式。

可以根据业务规模选择：

时间信息 + 随机数全局 ID 生成器基于数据库号段分配雪花算法一类的分布式 ID

无论使用哪种方案，至少要考虑：

是否全局唯一并发下会不会重复多机部署能不能正常生成长度是否适合存储和传递是否暴露明显的业务规律生成失败时怎么处理

订单号也不一定要完全没有规律。

有些系统会保留日期信息，方便客服辨认和按时间排查。只要不要把“看起来复杂”当成安全措施，也不要让生成规则破坏唯一性即可。

自增 ID 是不是完全不能对外？

也不是。

如果只是内部管理系统，访问者都是经过授权的员工，业务规模也很小，直接使用自增 ID 可能足够简单实用。

即使在面向用户的系统里，只要权限校验正确，暴露自增 ID 也不代表一定会发生越权。

所以这不是一条绝对禁令。

真正要判断的是：

这个编号会不会公开是否需要隐藏业务量系统未来会不会分库或迁移外部系统是否长期依赖这个编号

对外业务越复杂，越值得把内部主键和订单号分开。

简单总结一下

自增 ID适合做数据库内部主键 直接当成对外订单号容易被遍历，也可能暴露业务量 内部主键和业务订单号分开可以降低数据库结构与外部接口的耦合 订单号难猜不能代替权限校验唯一索引也不能省略

数据库自增 ID 不是不能用。

只是它更适合解决“这条记录在数据库里是谁”，而订单号还要解决“这笔业务如何安全、稳定地对外流转”。

两个编号各做各的事，系统通常会更从容。

原来如此。

阅读原文：点击这里​