mysql自动生成订单号

① 如何保证生成的订单号的唯一性

订单号不能采用时间戳的形式，因为不可能精确到秒，那样订单号过长 这种情况下只能在数据库这端进行控制，但是也没有看到数据库有类似oracle的序列 问题补充：如果每次都去数据库中查询的话效率就有问题了 问题补充：guoxu0514 写道担心效率问题的话，你可以考虑用缓存来解决，不会有什么事儿都有两全其美的解决办法。缓存也有问题，比如无法保证集群环境下订单号的唯一性 问题补充：nixiangyan 写道直接交个数据库管理不久行了吗这种情况下只能在数据库这端进行控制，但是也没有看到数据库有类似oracle的序列 如果将用过的订单号插到数据库中，每次取最大的，效率上会不会有问题 问题补充：nixiangyan 写道其实 我感觉吧，效率是相对的，当你提出某种要求的时候实质上很大的可能是在牺牲效率，交个数据库管理如果是自增的话，你可能会说订单号太单一，如果使用时间你说太长，还有使用时间为什么不能精确到秒？可以解释一下吗？ 我感觉做软件不能太在意效率了，呵呵，主要是客户给一定的规则，精确到秒的话订单太长了，效率问题倒是可以先不考虑 问题补充：hu437 写道可以这样做的，取最大的，不一定要是从源表里面取的，比如现在有一个订单表，我再加一个计数表 当每生成一个订单，我就同时将这个最大的订单号存到计数表里面，计数表里面可以只有两个字段，一个叫计数内容，一个叫计数值

② 我正在做一个餐饮系统，碰到了生成唯一订单号的问题。我想通过数据库自增 ID ，把自增ID作为订单号

一般是取机号、年，月，日加时间来区分的，自加ID，过一段时音就不易对帐了

③ 怎么随机生成的Id变成16位的订单号

关于生成订单号的解决方案
电子商务及类电子商务的系统越来越多，我相信订单号问题是这类系统中最常见不过的一个问题了，但今天还是想谈谈。
这几天由于工作需要接手了另外一同事前期开发的一个交易系统，原本使用的是uniqid()函数生成的。uniqid()是根据系统时间经过一定算法得到的一个结果，关于uniqid()的详情手册上很清楚。
当时的生产方式是：
$order_sn = str_replace('.', '', uniqid('', true));
这种方式理论上说会重复，但是在实际应用中我相信这种重复可以认为是不可能事件。但是，如果这件事情到此就结束的话我也就不会再写这篇文章。这几天做支付接入，国内某大型网络支付机构只支持传递最多16位的订单号，无奈我只得调整订单号的生产规则。
其实关于生成订单号的方式非常多，大致有以下几个参数被用到：1、自增字段，2、系统时间，3、随机数，4、流水号。
一、数据库自增字段
二、简单的使用系统时间
三、系统时间加随机数
四、系统时间加流水号
先说说数据库自增字段，这种方式是最简单有效的方式，但同时也存在很大的弊端：
1、以mysql为例的int类型最多存储10位的数字，如果使用bigint则在使用php的mysql_insert_id()取上次插入id时会出现错误，当然这个错误是可以采用某些方法避免的。
2、很多时候业务逻辑需要在数据未插入系统之前就获得订单号以进行一系列的处理，这样就容易出错。比如当并发较高的时候系统获取到下一次插入的ID应该是10000，可是当真正insert的时候发现10000已经被其他插入行使用。
3、很容易透露出系统的销量，从商业层面说这种方式不太合适。
4、表现不够直观，不能通过订单号简表达订单信息
简单的使用系统时间也可以有多种方式比如直接使用time()生成10位数字,这种方式基本避免了数据库自增字段的大部分弊端，但同时也产生的一些新的问题，比如：并发量稍高(峰值每秒一次以上,相信这是个很小的值)就会产生相同订单号，而这是业务逻辑所不允许的。为了解决重复订单问题而使用随机数或者流水号。
先说随机数，这东西就跟看上去的字面意思一样，总显得不那么可靠，我认为尽量不使用它参与唯一标识。
再说流水号，既然叫流水号，它的性质其实和自增字段一样，不同的是或许每天或者每月流水号又会重新计数。总得有个地方来保存下一个（或者当前使用过的最大）流水号的值，如果存在文件中那就需要考虑这个文件的读写锁的问题，就这个问题估计足够写书了，在此不予讨论。如果以自增方式存在DB中，那么我们在程序生成订单号之前需要多访问（至少）一次DB，这也就降低了程序性能，要知道数据库访问对程序的性能影响是非常明显的
上面是一大堆废话，说说我的解决思路(PHP)，当然同时别忘了大前提是：限制长度16位
第一步：
$order_sn = date('ymdHis').substr(microtime(),2,4);
其实这种方式基本已经满足需求了，无需访问DB无随机数参与。但是如果两次请求在相同的十万分之一秒内产生，那么相同订单就产生了，看能否有办法继续提高。
date(‘His’)所表达的结果其实就是000000到235959，而且其中很多数字不会被用到比如126998。一天86400秒，如果从一天的0:0:0算起直到23:59:59使用00000-86400就可以完全表示，这样下来我们就完全可以把date(‘His’)换成五位数字。既然time()函数就是按秒计数，那咱就取time()结果的后五位，同一天之内后五位不会重复出现，比如今天0:0:0后五位是98765，那么到今天23:59:59后五位就应该是98765+86400去掉最高位，相信这个应该是很好理解的。
这就产生了第二步的结果：
$order_sn = date('ymd').substr(time(),-5).substr(microtime(),2,5);
这样一来也导致无法直观的表达出订单生成的时分秒，但我认为(或者说从业务角度理解)这个属于可接受范围。同时这样处理出现重复订单的概率就降低到了第一步的1/10，我以为这应该不算一个小数字。还不满意？OK，那继续！
想要继续降低重复可能性那就继续提高时间精度，但是我们的长度限制只有16位，看来只有减少部分不长变动的字符。
date(‘ymd’)产生6位字符，而前两位在一年之内都不会变化，第三到第四位也就是01-12。
前两位我们可以使用A-Z的字母来表示，系统开始运行的那一年用A，第二年用B，第三年用C……类推，我相信我写的这程序运行不了10年。第三第四位完全可以使用一位16进制数表示，这样咱就又节约了两位字符，这就可以在末尾加上00-99的随机数。
现在看第三步的结果
$year_code = array('A','B','C','D','E','F','G','H','I','J');
$order_sn = $year_code[intval(date('Y'))-2010].
strtoupper(dechex(date('m'))).date('d').
substr(time(),-5).substr(microtime(),2,5).sprintf('d',rand(0,99));
理论上说出现重复订单号的概率又降到了第二步的1/100。
做个简单测试，写个php文件，连续10次echo出这三步结果得到的$order_sn,中间无任何多余程序。
第一种方案基本得到10个相同的结果。
第二种方案基本得到10个不同的结果，主要是后两位不同，一般末位差一。
第三种方案得到10个不同结果末四位不同
当然这个测试不具备多少说服力
优点：
1、不用操作数据库，性能较高。
2、较为直观，不难看出订单产生的大致时间
3、订单号重复的概率极小，只有程序在百万分之一秒内同时处理一个以上的生成订单号请求，而且同时生成的0-99的随机数也一样才会出现重复的订单号。

④ 数据库有个订单号是自动递增的，要求格式为YYYYMMDD（代表日期）以及有0000-9999组成，请大虾帮忙

你想错了，在数据库的那个订单号是由程序产生的 ，插入数据库，
string orderId= dateTime.now().tostring("YYYYMMDD")