訂單號是用來標記/查詢訂單（查詢的時候可能更關注於物流單號）用的，一般會在訂單有支付/售後/異常問題的時候會用到，也就是說訂單號主要是拿給客服/運營/開發部門用的。
根據訂單號就能得到一些資訊
訂單號：
1 純數字，盡量短
2 盡量能結合當前的業務情況有特定的標識，如渠道編號（包括平台、下單渠道、支付方式）、業務型別和時間資訊等
業務型別：以前在遊戲行業的時候，我們一般會把訂單號的某一位用來標識遊戲名稱，比如夢幻西遊、魔獸世界和陰陽師分別用1、2、3來標識。這樣遇到 相關問題時，不用後台查詢即可快速識別出問題並把其轉給相關遊戲團隊。同理的還有零售和**，自營訂單和入駐商家訂單，2b業務訂單和2c業務訂單；
時間資訊：有時間資訊會讓客服/運營人員看到訂單時不需要經過後台查詢即可知道該訂單時哪天產生的，可以簡單的判斷問題的緊急程度。同時在b2b業 務中，我們也可以根據該時間推算出大致的清分結算時間等等。所以我的建議是如果業務型別決定了客服類問題比較多，則有必要在訂單號裡面加上這個資訊。但時 間的完整格式2023年11月11日 11點22分33秒這樣的顯示出來就是20161111112233，年和時分秒資訊略顯多餘，只記錄月和日即可；
綜上，我給出的好用的訂單規則是這樣的：
********
下單渠道1位+支付渠道1位+業務型別1位+時間資訊4位+下單時間的unix時間戳後8位（加上隨機碼隨機後的數字）+使用者user id後4位。然後你會說，這樣算下來就訂單號就19位了啊，一點都不精簡啊，不好記不好念不好輸的。但我說的上面的這些業務標記，你不一定要全部加上啊。
你看**/天貓那麼大的訂單量，16位訂單號就搞定了。細心的網友已經發現了，訂單號的後4位是取自使用者user id的後四位，前12位中有10位可能是由unix時間戳加隨機規則生成的。
訂單系統設計 訂單號設計
三 因子分表法 唯一性 必要 每個訂單號全域性唯一代表乙個訂單 安全性 必要 訂單號不能透露訂單量 運營規模等業務資訊 資料安全性 高效能 訂單號的建立成本越低越好 擴充套件性 能夠較好的支撐後續業務發展變大帶來的分庫分表 訂單長度擴充套件等場景 不安全 訂單號能夠反映出系統的訂單量，存在業務資料外...
訂單號生成
之前用uuid 因為太長改用16位因此在網上找到一下這種做法,年月日擷取 時間戳 在加隨機數 生成乙個訂單 獲取年份 var date j f c d e b h i a date gettime tostring var ordersn date new date getfullyear 2015...
mysql 訂單號主鍵 為什麼不用訂單號當做主鍵？
1.普通索引上儲存的值是主鍵的值，如果主鍵是乙個很長的字串並且建了很多普通索引，將造成普通索引占有很大的物理空間 2.自增id 在插入的時候可以保證相鄰的兩條記錄可能在同乙個資料塊，而訂單號的連續性在設計上可能沒有自增id好，導致連續插入可能在多個資料塊，增加了磁碟讀寫次數。innodb儲存引擎邏輯...