訂單命名的幾種規則：
1、不重復。
這點我相信大家都懂，訂單的唯一性不用解釋。
2、安全性。
你的訂單編號不能透露你公司的真實運營信息，比如你的訂單就是流水號的話，那么別人就可以從訂單號推測出你公司的整體運營概括了。所以訂單編碼必須是除了你們公司少部分人外，其他人基本看不懂的。參考京東和淘寶的編碼規則，基本別人是搞不清是什么意思的。
其實最好的防泄漏編碼規則就是在編碼中不要加入任何和公司運營的數據。
3、不能使用大規模隨機碼。
很多人分析訂單編碼規則的時候，第一個念頭肯定是不重復唯一性，那么第二個念頭可能就是安全性，那么同時滿足前兩者的第三個念頭就是隨機碼了。因為大規模的隨機碼隨機生成，因為本身就沒有意義所以無所謂泄密了。但是事實上這種編碼規則在實現上會有很大問題的。
隨機碼滿足第二點安全性要求，為了滿足第一點不重復特性，那就得在生成隨機碼的時候對比歷史數據是否有重復，如果你的訂單數量到達了十萬次，你每次生成訂單編碼時就得對比十萬條歷史數據，你可想而知會造成什么巨大問題。
但是難道隨機碼就不能在編碼中使用了嗎？小規模的隨機碼是可以使用的，比如2~3位，這種隨機碼一般都是和流水號等結合使用，主要作用是為了隱藏流水號的真實數據而進行使用的。
PS:在這里感謝 @馬馳@dad ni @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位之內，位數比較多。
（以上來自知乎@benben）
==============================================
訂單號常見的幾種方式：
1.利用數據庫主鍵值產生一個自增長的訂單號（訂單號即數據表的主鍵）
2.日期+自增長數字的訂單號（比如：2012040110235662）
3.產生隨機的訂單號(65865325365966)
4.字母+數字字符串式，字母有包含特別意義，C02356652
訂單號設計原則： 按需設計
用來檢索訂單詳細信息的唯一特征碼，可以利用訂單號檢索到下單日期、產品類別、顏色、尺碼（或款式）、倉位等信息，訂單號包含過多的信息有點“畫蛇添足”的意味！只要按需設計即可！
訂單號設計用戶體驗規則：
1.訂單號無重復性；
2.如果方便客服的話，最好是“日期+自增數”樣式的訂單號，客服一看便知道訂單是否在退貨保障期限內容；
3.訂單號長度盡量保持短（10位以內），方便用戶，尤其電話投訴時，長的號碼報錯幾率高，影響客服效率；
4.訂單號盡量保持數字型(純整數)，在數據庫訂單索引查詢中，長整數字型的數據索引與檢索效率，遠遠高於文本型，因此盡量避免“字母+數字字符串式”！