https://www.zhihu.com/question/19805896#answer-31069940
你是个程序员。
隔壁老王通过你老婆找到你，说要做个"巨牛逼电商网站"，并许诺给你股份若干，你想想首付也攒了好久，就差200万就够了，于是就同意了，你花了一个星期做了一个网站并上线运营，订单号格式如下：
日期+6位自增数字
例如：
20160301000001
20160301000002
20160301000003
20160301000004
...
你很开心，这天你加班改完bug回家，老王从你的衣柜里跳出来对你说，不行啊大兄弟，为什么对门老张的"超屌电商网站"每天都知道我们有多少订单量呢？
没办法，你只能回去继续修改代码。
这就是最基本的流水号的问题，不仅仅会暴露你的交易量，而且有规律的订单号很容易成为安全隐患。
你又把订单号改为即时生成‘日期+6位随机数字’，并且也做了重复检查，心想这回应该没问题了吧，运营了一周之后，半夜里老王又从你的床底下爬出来说，不行啊大兄弟，为什么每天晚上下单都很慢/下单失败（取决于失误的大小）呢？。
没办法，你只能回去继续修改代码。
这就是即时随机数的问题，不仅仅是检测重复的性能差，你想一下一共六位数字理论值100万条，假设当天下单记录已有80w，接下来再下单可能会不断的随机并且产生的随机数都已经存在，而且，这种方式并发如果处理不好就会导致下单失败（数据库unique）或者相同订单号（数据库非unique）。
你苦思冥想，终于想到了解决办法，我每天把明天要用的订单号先随机好，放进redis之类的缓存里里随用随取，这样就不会有性能和并发的问题了，回家发现老婆不在家，于是你开心的玩起了dota。
这里已经很接近订单池的概念了，不过因为这个池子没有流动性，就让我们暂且叫做订单桶吧，每天都要往桶里打水。
随着用户量的增长，你们决定在三月三号做一个"对3促销节"，你在办公室监视着服务器，突然老王用你家座机给你打电话，大兄弟你快看下，下不了单了，你熟练的连接上服务器查找着问题，发现生成的订单号已经被用完了，这一天的促销不得不停止。
于是你又连续加班了三个月，做了一个实时监控订单号熟练的系统，当低于xxxxx的时候迅速生成新的订单号，并且买了更多的服务器，做了更多的集群，可以同时预留出更多的订单号等等等等。
**这就是现在订单池的概念，随着订单号的被消费还继续生成着订单号，这个涉及的内容就很复杂了。**
我讲这个故事不是想说隔壁老王跟你老婆的关系，也不是房价到底有多贵，创业公司到底怎么样，而是软件开发往往不是 一蹴而就的，所有的东西都是不断进化的，你不可能起步就按照京东淘宝的标准来，根据实际情况实际分析就可以了， 脱离需求谈实现都是耍流氓，比如就是一个内部的ERP，用户不超过200，每天生成订单量不超过50，用自增有问题么？我觉得没问题啊。你说呢。
1.三个真实的案例
案例1：最近面试的将近20位产品经理里面，我都会问一道问题：请您为我公司的订单系统设计一套订单号的生成规则。应聘者里面有一两年的职场新人，也有工作将近十年的老鸟，当然也不乏运营或者开发转岗到产品的，有些甚至还做过订单与支付系统，但几乎所有的面试者都没能说的很全面。
案例2：去年的某个时间，朋友A所在的公司订单系统改造升级，开发在没有知会运营和市场的前提下将订单号长度由14位改到了19位（事后得知产品人员当时也不知情），而公司现有的用户至少70%都在使用货到付款的刷卡支付，即每次刷卡前都需要输入订单号，然后你懂的，整个市场炸锅了，开发于是紧急发版，又把订单号的长度改回了14位。
案例3：再说说6年前的一个经历。当时朋友（简称为C吧）在一家游戏公司做PHP网站开发，C和其他几位开发完成了整个游戏的在线支付系统，并且联调成功了。系统运行后发现了一个情况，某游戏玩家充值了5万块钱，当时运营人员想查下是什么时间充值的，但后台系统里面没有记录充值时间，无奈之下只能去数据库查到了时间戳，然后根据时间戳反查出来了充值时间。
2.订单号的生成规则
再回到上述案例1里面的问题，其实题干里面还隐含了一个关节信息，即该系统是为我公司设计的，而不是其它公司设计的（我公司现在做酒饮类B2B，未来可能会做B2C或其它）。但回答者几乎都忽略了这一点。
这些应聘者的原话记不清了，但主要就以下这些思路及其组合，括号里面是我的点评（吐槽）：
- 订单号由数字和字母和连字符-组成（您考虑过英文和拼音发音分不清楚的用户么？连字符起什么作用？）；
- 订单号由时间/年月日时分秒和随机数组成（仅时间20161111112233就14位了啊，随机数你打算再来几位？考虑到支付峰值每秒10万笔订单，系统怎么来随机？再加5位数？）
- 订单号前几位标识商品，比如茅台编码是001，五粮液是002，既有茅台又有五粮液是003，后面由日期+随机码构成（商品标记会有什么意义？即便商品数量只有几十个的情况下，他们的排列组合也很多啊，这个得多少位？）；
- 由下单日期+用户手机号+随机数构成（即便日期只取月和日会占4位，加上11位手机号也15位了，而且日期会重复，每个用户每天可能会下很多单，而且用户手机号不具有唯一性。后来有人提过类似的规则，只不过将用户手机号换成了唯一的user id，但user id还是会很长）；
- 根据卖家和买家的ID+随机数生成订单号(如果是C2C网站，用户体量在几千万上下，这样就需要至少8位来标记用户ID，随机数即便1位的话订单号也得17位，但实际情况有可能买家经常在某个卖家那买东西，3位随机码都不一定够用)；
- 根据商品的品类+时间+随机数生成订单号（他没有具体说是大的品类还是小的品类，如果是小的品类，可能也会很多）；
那么问题来了，一个好用又好看的订单号，应该具备哪些规则和依据呢？
关于这个问题，知乎和简书上都有很多相关的讨论，比如这篇《电子商务网站中订单号设计有什么规则和依据吗？》和这篇《电商订单号设计思考》，里面一些关于订单号的生成规则和依据很值得参考，在此，我说点自己的经验和见解。
3.订单号怎样生成才好用
回到问题的本质，订单号是拿来干嘛用的？谁会关注订单号？简而言之，订单号是用来标记/查询订单（查询的时候可能更关注于物流单号）用的，一般会在订单有支付/售后/异常问题的时候会用到，也就是说订单号主要是拿给客服/运营/开发部门用的。
那么客服在处理一笔订单的时候，什么格式的订单号才会好用呢？首先订单号中最好避免数字以外的其它字符类型，订单号尽量短，订单号尽量能结合当前的业务情况有特定的标识，如渠道编号（包括平台、下单渠道、支付方式）、业务类型和时间信息等。为了便于理解，下面还是举例说明：
- 平台：这个以游戏举例，目前很多手游除了官方服务器外，还有一些是和其它平台比如小米、腾讯联合运营的，但是充值有可能是用的同一套，这种情况就很有必要在订单号中标记平台；
- 下单渠道：目前很多电商产品都涵盖多平台，包括WEB、APP（Pad）和门店（比如1919和苏宁等），比如通过订单号发现近期反映的问题都来自于APP，则理论上可以推断出APP渠道有问题。
- 支付渠道：如上文案例2所说，不同支付方式会遇到的问题也是不一样的，比如货到付款的刷卡支付仅POS机错误代码就几十项，而支付宝基本不会有这些。比如APP不支持公司转账，如果某订单有了代表公司转账的标识位，不用后台查询即可知道这是一笔来自WEB的订单等等。同样，用户反映该订单号无法使用红包，客服人员也可以通过支付渠道标识位来识别出是因为红包功能在APP上没有上线造成的；
- 业务类型：以前在游戏行业的时候，我们一般会把订单号的某一位用来标识游戏名称，比如梦幻西游、魔兽世界和阴阳师分别用1、2、3来标识。这样遇到相关问题时，不用后台查询即可快速识别出问题并把其转给相关游戏团队。同理的还有零售和团购，自营订单和入驻商家订单，2B业务订单和2C业务订单；
- 时间信息：有时间信息会让客服/运营人员看到订单时不需要经过后台查询即可知道该订单时哪天产生的，可以简单的判断问题的紧急程度。同时在B2B业务中，我们也可以根据该时间推算出大致的清分结算时间等等。所以我的建议是如果业务类型决定了客服类问题比较多，则有必要在订单号里面加上这个信息。但时间的完整格式2016年11月11日 11点22分33秒这样的显示出来就是20161111112233，年和时分秒信息略显多余，只记录月和日即可；
综上，我给出的好用的订单规则是这样的：
下单渠道1位+支付渠道1位+业务类型1位+时间信息4位+下单时间的Unix时间戳后8位（加上随机码随机后的数字）+用户user id后4位。然后你会说，这样算下来就订单号就19位了啊，一点都不精简啊，不好记不好念不好输的。但我说的上面的这些业务标记，你不一定要全部加上啊。
你看淘宝/天猫那么大的订单量，16位订单号就搞定了。细心的网友已经发现了，订单号的后4位是取自用户user id的后四位，前12位中有10位可能是由Unix时间戳加随机规则生成的。
然后我们再来看看《电商订单号设计思考》中提到的那2个问题：
问题1：为什么淘宝单号这么长？前几年还12、13位，现在都16位了？订单号之所以那么长，我的理解是短了不够用，毕竟那么大的用户基础和订单量。至于现在都是16位？我查询了2011年的淘宝订单，发现是14位的，并不是该简友说的12/13位，但由14位扩充到16位，应该很大一部分原因是业务增长的原因。
问题2：为什么自己的淘宝单号最后4位都一样呢？这4位数字代表什么？2011年3月之前的订单，后4位是不一样的；3-7月之后（4/5/6三个月我没有下过单）的淘宝订单，后4位是一样的。我猜想可能是user id，后来我验证了下，一定程度上是的，比如我的ID后4位是1190，订单的后4位是9910，由此看来，淘宝订单后4位是将user id后4位简单处理过的。至于前12位，我 猜想其中有10位可能是由Unix时间戳加随机规则生成的。
4.订单号怎么生成才好看呢？
相信很多人都受够了银行卡上面不分段的银行卡号了吧，还有就是快递单上面不分段的快递单号码（顺丰的就很好），这些简直就是反人类设计。其实订单系统里面也可以借鉴顺丰的这个思路分段显示，方便查看和诵读。
如果做的再智能点，支持WEB上双击复制或者APP上长按复制（点击后可复制），是不是更好看更人性化更便捷了呢？
5.几句题外话
前几天我看到了宅妈妈APP的订单号，4位纯自增的数字，极其精简。当时我就在想他们为什么会把订单号设计这么短，后来仔细想了下她们的具体业务情况，或许是这样的：处于业务开拓起步阶段的宅妈妈不希望用户在反馈问题时报上冗长的订单号，同时她们希望用户通过订单号能感受到该APP有很多人在使用并下单，进而打消她们的部分顾虑。
滴滴出行因为每次行程都有司机车牌号，所以在遇到问题时直接反馈“时间+起点+车型车牌号”可能更方便。饿了么同理，我在反馈问题的时候也不会去报订单号，直接报时间和商家名更方便，订单号可能在客服处理问题的时候会用的更多一点吧。
因为前段时间涉及到设计电商订单编号的问题，所以对这个问题确实研究了一段时间，有一些收获分享给大家。
本文主要是讨论电商的订单编码规则，如果是对内的ERP系统，订单编码则以简单易懂为主，因为外部人也看不到。
不废话，直接干货。
订单命名的几种规则：
1、不重复。
这点我相信大家都懂，订单的唯一性不用解释。
2、安全性。
你的订单编号不能透露你公司的真实运营信息，比如你的订单就是流水号的话，那么别人就可以从订单号推测出你公司的整体运营概括了。所以订单编码必须是除了你们公司少部分人外，其他人基本看不懂的。参考京东和淘宝的编码规则，基本别人是搞不清是什么意思的。
其实最好的防泄漏编码规则就是在编码中不要加入任何和公司运营的数据。
3、不能使用大规模随机码。
很多人分析订单编码规则的时候，第一个念头肯定是不重复唯一性，那么第二个念头可能就是安全性，那么同时满足前两者的第三个念头就是随机码了。因为大规模的随机码随机生成，因为本身就没有意义所以无所谓泄密了。但是事实上这种编码规则在实现上会有很大问题的。
随机码满足第二点安全性要求，为了满足第一点不重复特性，那就得在生成随机码的时候对比历史数据是否有重复，如果你的订单数量到达了十万次，你每次生成订单编码时就得对比十万条历史数据，你可想而知会造成什么巨大问题。
但是难道随机码就不能在编码中使用了吗？小规模的随机码是可以使用的，比如2~3位，这种随机码一般都是和流水号等结合使用，主要作用是为了隐藏流水号的真实数据而进行使用的。
PS:在这里感谢
@bao xu（这个不知道为何@不到）同学的讨论，马驰同学实际测试估算了生成随机码并且检测重复所花费的时间在纳秒级别。但是我还是保持原来观点，觉得这种生成规则存在方向性问题，可能会造成检测时间过长的问题出现。希望大家积极参与讨论。
4、防止并发。
这条规则主要针对编码中有时间的设定。
5、控制位数。
这点很好理解，订单号的作用就是便于查询。
一般正常使用场景应该是订单出异状或者退货的时候，用户将订单号报给客服，由客服进行查询。
所以一般在10~15位为好。
京东10位，淘宝15位。
推荐的几种编码规则：
年月日时分秒+用户ID(命名用户ID时也要注意，不要用流水号。可以采用区域ID+随机码+流水号+随机码方式)
1、唯一性：时间是单向的，确保唯一性。
2、安全性：确保用户ID安全即可。
3、随机码不参与判断，因为之前数据已确保无重复。
4、在同1秒钟，同一用户是不会产生2个订单编码的，所以可以防并发。
5、位数可能会在20位之内，位数比较多。
年月日时分秒微秒+随机码(2)+流水号+随机码(3)
1、唯一性：时间是单向的，确保唯一性。
2、安全性：确保流水号不会识别出即可。
3、随机码的位数和前后都是保密的，所以如果不清楚这一点的话，是很难判断出流水号的位数的。因为同时产生的订单数量很多，编码不具备线性对比功能。就算知道了流水号，可以在初始化时进行赋值。
4、在同1秒钟，同一用户是不会产生2个订单编码的，所以可以防并发。
5、位数可能会在20位之内，位数比较多。
毕竟如果搜到这问题的都是想解决这问题的，进行思考参与讨论，才是大家的原本目的。
订单号在电子商务网站设计有一定讲究，从用户体验和数据库优化的角度来看：
订单号常见的几种方式：
1.利用数据库主键值产生一个自增长的订单号（订单号即数据表的主键）
2.日期+自增长数字的订单号（比如：2012040110235662）
3.产生随机的订单号(65865325365966)
4.字母+数字字符串式，字母有包含特别意义，C02356652
订单号设计原则： 按需设计
用来检索订单详细信息的唯一特征码，可以利用订单号检索到下单日期、产品类别、颜色、尺码（或款式）、仓位等信息，订单号包含过多的信息有点“画蛇添足”的意味！只要按需设计即可！
订单号设计用户体验规则：
1.订单号无重复性；
2.如果方便客服的话，最好是“日期+自增数”样式的订单号，客服一看便知道订单是否在退货保障期限内容；
3.订单号长度尽量保持短（10位以内），方便用户，尤其电话投诉时，长的号码报错几率高，影响客服效率；
4.订单号尽量保持数字型(纯整数)，在数据库订单索引查询中，长整数字型的数据索引与检索效率，远远高于文本型，因此尽量避免“字母+数字字符串式”！
1，要确保唯一性
2，为了更好的实现1，尽可能在的规则上就能够避免订单号出现冲突，减小冲突可能出现的范围。比如，同一个店铺下的单号冲突的可能性，总好过 全站范围内的单号冲突。
3，订单尽量带有一定的语意性，但这个语意表达的应该是一种公开的、非隐私的信息。比如，可以出现日期，可以出现店铺的ID，但不能出现购买者的ID。
4，因为订单号不是做作为主键，就是作为唯一键，所以尽量单调递增，否则会影响到存储的性能。
5，如果系统的存储是在数据库，并且分库分表的话，那单号的最后几位（或者其它固定位置的几位）是数字，这样可以用数字作为分库分表的规则。
5，如果你们的系统特别复杂，甚至是多地分布式的部署。那可能还要有一两位来表达系统部署的路由规则。
6，综上，订单号的规则、长度，尽量是固定的。
7，如果你们的电子商务网站的流量特别大，那生成单号就会是一个非常繁忙的服务，尽量让规则能够使用分布式的部署，避免造成性能的瓶颈。
最简单粗暴的建议：
-店铺ID+日期+路由ID+递增数字。
递增数字可以归零。只要确保同一天，同一个店铺的订单量，不超出 递增数字预留空间的最大位即可。
这里不建议把日期精确到时间戳，因为多台机器的时间可能会存在一点点误差，时间戳要求的越精确，那多台机器之间，产生冲突的可能性就越大。
推荐使用日期的一个好处，是因为在语意里面，日期是一个经常用到的字段，比如，业务对账里面，经常是按照天 来对账的。
所以，里面包含日期的话，后面好处理。
//-------------
另外，尽量不要依赖数据库的递增服务，尽量是有一个专门的服务，来负责 这个计数器，这样在以后的迁移、扩展上，会有灵活的余地。
如果业务量小，那么依赖一个单一的节点（比如说数据库），是足够的，而且简单粗暴。
但如果业务量大，那这个单一的节点，就是一个很危险的性能瓶颈。
假设已经到达了这个程度，那就可以让递增计数落到N台机器上，返回的结果中，预留N位用作机器ID的标识，每台机器上自己负责递增，但因为结果中有机器ID存在，所以就不需要考虑 冲突。
每台机器上自己递增，就把互斥的范围一下子压缩了。
2.个人喜好：
----1.如果要保密，直接上随机数最好。当然内部数据库是按自增保存的。
......关于随机数的性能，其实非常简单：
......一次性生产N * N的随机数子集转轮算法 + 提前计算 + 批量发放，一点问题都没有。
----2.如果不保密，其实自增是最好的。
某东订单分析
只做学术研究，禁止转载，转载后果自负，有事情联系本人，感谢知友们。
①、
20780458090
20780452514 以上是家电类目下同一个产品的两个连续定单号
20655284548 家电类目下另一个产品的订单号。
20647416054 非家电类目下的订单。
时间差在1小时内的订单，订单时间是2016/8/2。
②、
20698237511 订单日期：2016-08-02
20695306175 订单日期：2016-08-01
以上是同一产品，家电类目下的订单。订单日期相差一天。
③、
19451361389
19511676368
非家电类目，时间差小于两分钟下的订单。订单日期是2016-06-03。
通过②可以看出，第5-7位很可能是日期区别，具体算法无法得知（2） 。
通过①②可以看出，第3-4位是不同产品的区别码，其实简单一想应该不是产品区别码，因为只有两位数，那么具体作用无法得知（3）.
通过①②③，我们可能会看出随着时间的推移，前两位是递增的，但是不是简单的按照时间或者月份递增的，因为6月份的订单是19, 7、8月份的是20，再往之前5月份是18。所以确定是递增的，具体算法无法得知（4）。
<img src="https://pic1.zhimg.com/50/8e4eaca74ac049a503895ac647410b3c_hd.jpg" data-rawwidth="819" data-rawheight="460" class="origin_image zh-lightbox-thumb" width="819" data-original="https://pic1.zhimg.com/8e4eaca74ac049a503895ac647410b3c_r.jpg">
从这个例子分析入手，再结合以上先知友的回答，相信众多猿类知友就更加清新大型订单业务量的规则设计了。曾经看过很多连锁的ERP订单规则是：年月日+机构编码+后四位随机。（今天就去超市消费，分析下他们的小票上的单号吧，万一是傻瓜式的递增，又碰巧店铺做活动：尾号是xx的有大奖，那你就蹲点捡便宜吧，哈哈哈）。
当然随着技术的发展和经验的不断积累，现在的合格的订单规则就应当如某东某宝等网站一样，不透漏任何业务信息，包括时间等信息都不能让居心叵测的竞争商家或者黑客知道。
著作权归作者所有。
商业转载请联系作者获得授权，非商业转载请注明出处。
作者：DongLin
链接：http://www.zhihu.com/question/19805896/answer/56592756
来源：知乎
2，为了更好的实现1，尽可能在的规则上就能够避免订单号出现冲突，减小冲突可能出现的范围。比如，同一个店铺下的单号冲突的可能性，总好过 全站范围内的单号冲突。
3，订单尽量带有一定的语意性，但这个语意表达的应该是一种公开的、非隐私的信息。比如，可以出现日期，可以出现店铺的ID，但不能出现购买者的ID。
4，因为订单号不是做作为主键，就是作为唯一键，所以尽量单调递增，否则会影响到存储的性能。
5，如果系统的存储是在数据库，并且分库分表的话，那单号的最后几位（或者其它固定位置的几位）是数字，这样可以用数字作为分库分表的规则。
5，如果你们的系统特别复杂，甚至是多地分布式的部署。那可能还要有一两位来表达系统部署的路由规则。
6，综上，订单号的规则、长度，尽量是固定的。
twitter 的[SnowFlake](https://github.com/twitter/snowflake)算法解决了排名第一阐述的大部分问题。
简单来说:
sknowflake是一个多线程安全的，基于时间（微秒时间戳）的，固定长度的（18位）的纯数字随机id系统。
关于电商订单号，网购一族一定不陌生。其实也不熟悉，想想谁会对一串数字/字符感兴趣呢？如果不需要售后服务，正常情景下我们是不会去关注那一串字符的。当哪天关注到订单号的时候，甚至感兴趣研究起电商订单号的，估计会被这一串字符背后的设计逻辑给震撼。
原来，这不起眼的小东西，还蕴含这么多值得思考的东西。
1、为什么淘宝单号这么长？前几年还12、13位，现在都16位了？
2、为什么自己的淘宝单号最后4位都一样呢？这4位数字代表什么？
3、凡客单号是日期+订单量吗？
4、从订单号可以推算出竞品的销量吗？
5、从订单号可以判断出竞品业务发展的速度吗？
6、从订单号可以猜想出竞品的业务策略和布局吗？
7、如何解决订单号重复的问题？
8、如何解决业务发展快，订单号长度不够用问题？
9、客服OR物流如何快速解读订单号的关键信息，从而提高工作效率？
10、业务变更，如果有拆单等需求，如何设计编码来满足业务的灵活和拓展需求？
11、编码变长之后，如何解决数据库的存储和读取性能？
等等等等
（图 by 榜耶--电商订单号结构化思考）
以下小故事摘录知乎：
电子商务网站中订单号设计有什么规则和依据吗？ - 数据库设计 - 知乎
日期+6位自增数字
这就是最基本的流水号的问题，不仅仅会暴露你的交易量，而且有规律的订单号很容易成为安全隐患。
即时生成‘日期+6位随机数字’
这就是即时随机数的问题，不仅仅是检测重复的性能差，你想一下一共六位数字理论值100万条，假设当天下单记录已有80w，接下来再下单可能会不断的随机并且产生的随机数都已经存在，而且，这种方式并发如果处理不好就会导致下单失败（数据库unique）或者相同订单号（数据库非unique）。
你苦思冥想，终于想到了解决办法，我每天把明天要用的订单号先随机好，放进redis之类的缓存里里随用随取，这样就不会有性能和并发的问题了，回家发现老婆不在家，于是你开心的玩起了dota。
这里已经很接近订单池的概念了，不过因为这个池子没有流动性，就让我们暂且叫做订单桶吧，每天都要往桶里打水。
随着用户量的增长，你们决定在三月三号做一个"对3促销节"，你在办公室监视着服务器，突然老王用你家座机给你打电话，大兄弟你快看下，下不了单了，你熟练的连接上服务器查找着问题，发现生成的订单号已经被用完了，这一天的促销不得不停止。
于是你又连续加班了三个月，做了一个实时监控订单号熟练的系统，当低于xxxxx的时候迅速生成新的订单号，并且买了更多的服务器，做了更多的集群，可以同时预留出更多的订单号等等等等。
这就是现在订单池的概念，随着订单号的被消费还继续生成着订单号，这个涉及的内容就很复杂了。
以下设计规则摘录知乎：
电子商务网站中订单号设计有什么规则和依据吗？ - 数据库设计 - 知乎
从用户体验和数据库优化的角度来看
1.利用数据库主键值产生一个自增长的订单号（订单号即数据表的主键）
2.日期+自增长数字的订单号（比如：2012040110235662）
3.产生随机的订单号(65865325365966)
4.字母+数字字符串式，字母有包含特别意义，C02356652
5.订单号无重复性；
6.如果方便客服的话，最好是“日期+自增数”样式的订单号，客服一看便知道订单是否在退货保障期限内容；
7.订单号长度尽量保持短（10位以内），方便用户，尤其电话投诉时，长的号码报错几率高，影响客服效率；
8.订单号尽量保持数字型(纯整数)，在数据库订单索引查询中，长整数字型的数据索引与检索效率，远远高于文本型，因此尽量避免“字母+数字字符串式”！
作者：榜耶
版权所有：公众号笔记Bang（notesbang）
综上所述，id生产规则基本包括
基本需求+高级需求+定制化需求
基本需求：正确性、唯一性、安全性、稳定性
高级需求：检索性能、其他性能方面
定制化需求：语义相关、业务相关
我现在用的订单号规则生成的订单范例如下
参考 ID
174118032468
1分钟间隔 ID
174118192145
1天间隔 ID 有多种可能，针对参考 ID 是。
184228143195
1天间隔 ID 另一个范例
232578032154
172018052351
有的公司的订单可以从订单号中看到这个订单对应的品牌、产品分类、产品型号、销售日期、负责部门或负责人、售后负责人等。商家只要拿到这个订单号就知道给谁处理。
看了一遍，没有我的这种方式，答一个：
一年有525600分钟（这是6位），使用年月日表示为：201802051235（这是12位）
一年有31536000秒（这是8位），使用年月日表示为：20180205123559（这是14位）
简单来说就是利用时间戳而不用日期时间，因为日期时间比时间戳位数要长，下面就是以分钟时间戳举例：
订单号的前七位表示分钟的时间戳，从网站上架时间算起，位数从1000001开始（这样的话起码可以支撑十几年）
中间4位代表商品ID，位数也从1001开始
最后4位随机码，如：5217
这样生成的订单号就已经足够了，如果用钱8位用秒的时间戳也可以（通常及时这样的情况下还可以支撑3年，基本3年之后技术更新换代，很容易了）
另外如果考虑到用户需要使用订单号的场景较多，用户在点击订单号时自动复制到粘贴板，
看了这么多，我们自己的处理是：日期（精确到秒）+会员ID（转成哈希数取后面6位数）
日期：精确到秒，共14位
会员ID：由于我们会员ID是1到N递增位数不固定的数值，我们将会员ID转化为哈希数字，这样每个会员ID就有专属的且同样位数的ID。我们取自，尾数6位数
这边就可能会出现尾数6位数相同的会员ID在同一秒生成订单，我们设置系统只会让一个订单生成，其他同秒内的订单生成都会显示“订单创建失败”。这样做是基于一般情况下在同一秒进行多次订单的创建都是通过非法的手段的恶意操作者，我们直接显示错误提示就行，不会影响用户体验。
其实凡是这些可以和上级沟通确认一下关于订单号的具体需求，比较有利于你开展工作
简单罗列下：
（1）日期规则1：yyyyMMddHHmmssnnn，精确到毫秒
（2）日期规则2：yyyyMMddXXX，最后三位为序号
（3）数字规则1：直接拿订单记录的自增整型关键字，从1开始递增
（4）数字规则2：固定位数，比如6位，从100000开始递增，不要用0开头
（5）字母+日期规则或数字：字母前缀在有些场景有用，比如分销售区域等，当然，你用数字编码来区分区域也行
很多，同意 LO 的建议：按需设计即可。
补充：不建议使用随机数字，不利于检索和查看。
853
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
