首先，id列一般作为主键，没有业务意义。设计的目的是方便查询和索引。如果使用单个表，它通常被设置为自动递增。订购后，无论是数据库还是业务的检索效率都非常高。

在分布式场景下，单一的表已经不能满足我们的需求，所以不适合使用自增id的方案。比如我们设计table表的时候，如何生成主键列就成了问题。流行的方法是使用类似雪花的算法来计算一个趋势排序值作为id。(当然还有很多其他方法)这在一定程度上满足了可扩展性，解决了检索性能的问题。

一般订单号的生成都有相应的规则，这些规则都是产品根据自身条件自行设计的结果。

举几个例子。

JD。COM的:

淘宝的:

可以看到，JD.COM和淘宝的订单数量都在增加，淘宝的订单数量似乎也是有规律的。查了一下这个，据说淘宝从2017年开始升级订单，用订单号的后四位识别用户，2017年以后改成了后六位。

"

那么淘宝订单号的后6位和用户id的后6位是什么用途呢？

我搜了百度和知乎，都找不到答案。

一个偶然的机会，我翻到一个淘宝技术进化的PPT，看到订单表分库的逻辑，恍然大悟。

一般平台型电商订单量都比较大。为了保证查询和检索速度，它将采用子数据库的形式来存储海量的订单信息。一般来说，订单系统维护订单号和userid之间的关联关系。首先根据订单号找到userid，然后根据userid确定子表来查询内容。而淘宝则在订单号上下足了功夫，通过订单号的后六位直接锁定库表，大大提升了高并发下的系统查询性能。

从这个策略中我们也可以看出，淘宝用户订单数据库是按照用户id的后6位存储的，比如XXXX452154格式的用户订单存储在一个子数据库中。

"

通过查询发现我的淘宝id后六位是107280，而我的订单号后六位是108072，还是正规的。

2012年找了一个淘宝PPT，12年前的设计可能不一样。

无重复显然，这个唯一的数字是不能重复的。

安全不能人为猜测或推断。

易识别易识别是指位数不要太长。如果位数控制得好的话，查询检索会比较容易，并且空占用的空间也小。

几个常用规则

前提是你按照自己设计或选择的订单号规则生成一个可行的订单号。在这种情况下，如果您的订单号包含字母等字符，那么不适合作为主键。虽然是唯一的，但索引查询性能很差。但是它可以是唯一的索引。

订单号是纯数字怎么办？

也不推荐。当然，数字有其优势和良好的性能(即使位数很长)，但毕竟订单号与业务相关，业务相关列作为主键本身可能会有问题。

如果以后要改变业务含义，可能要把数字改成字母，加几个数字或者更少，那么就必须修改主键。但是修改核心数据表的主键会造成很大的维护开销。

虽然直观上感觉“多了一栏”，但也不是一无是处，对以后的扩展性有很大的帮助。综上所述，回答我们题目的问题:“订单号和id列可以是同一列吗？”或者订单号可以作为主键吗？我觉得可以，但是不合适，所以建议不要用订单号作为主键。使用与业务无关的id列作为主键更合适。

如何设置主键列？

如果是单桌，当然是自增id。如果按子数据库考虑子表，可以采用类似雪花的生成方案。