以下故事僅供參考：

#############################################################################################

你是個程式設計師。 隔壁老王通過你老婆找到你，說要做個"巨牛逼電商網站"，並許諾給你股份若干，你想想首付也攢了好久，就差200萬就夠了，於是就同意了，你花了一個星期做了一個網站並上線運營，訂單號格式如下： 日期+6位自增數字 例如： 20160301000001 20160301000002 20160301000003 20160301000004 ... 你很開心，這天你加班改完bug回家，老王從你的衣櫃裡跳出來對你說，不行啊大兄弟，為什麼對門老張的"超屌電商網站"每天都知道我們有多少訂單量呢？ 沒辦法，你只能回去繼續修改程式碼。 這就是最基本的流水號的問題，不僅僅會暴露你的交易量，而且有規律的訂單號很容易成為安全隱患。 你又把訂單號改為即時生成‘日期+6位隨機數字’，並且也做了重複檢查，心想這回應該沒問題了吧，運營了一週之後，半夜裡老王又從你的床底下爬出來說，不行啊大兄弟，為什麼每天晚上下單都很慢/下單失敗（取決於失誤的大小）呢？。 沒辦法，你只能回去繼續修改程式碼。 這就是即時隨機數的問題，不僅僅是檢測重複的效能差，你想一下一共六位數字理論值100萬條，假設當天下單記錄已有80w，接下來再下單可能會不斷的隨機並且產生的隨機數都已經存在，而且，這種方式併發如果處理不好就會導致下單失敗（資料庫unique）或者相同訂單號（資料庫非unique）。 你苦思冥想，終於想到了解決辦法，我每天把明天要用的訂單號先隨機好，放進redis之類的快取裡裡隨用隨取，這樣就不會有效能和併發的問題了，回家發現老婆不在家，於是你開心的玩起了dota。 這裡已經很接近訂單池的概念了，不過因為這個池子沒有流動性，就讓我們暫且叫做訂單桶吧，每天都要往桶裡打水。 隨著使用者量的增長，你們決定在三月三號做一個"對3促銷節"，你在辦公室監視著伺服器，突然老王用你家座機給你打電話，大兄弟你快看下，下不了單了，你熟練的連線上伺服器查詢著問題，發現生成的訂單號已經被用完了，這一天的促銷不得不停止。 於是你又連續加班了三個月，做了一個實時監控訂單號熟練的系統，當低於xxxxx的時候迅速生成新的訂單號，並且買了更多的伺服器，做了更多的叢集，可以同時預留出更多的訂單號等等等等。 **這就是現在訂單池的概念，隨著訂單號的被消費還繼續生成著訂單號，這個涉及的內容就很複雜了。** 我講這個故事不是想說隔壁老王跟你老婆的關係，也不是房價到底有多貴，創業公司到底怎麼樣，而是軟體開發往往不是一蹴而就的，所有的東西都是不斷進化的，你不可能起步就按照京東淘寶的標準來，根據實際情況實際分析就可以了，脫離需求談實現都是耍流氓，比如就是一個內部的ERP，使用者不超過200，每天生成訂單量不超過50，用自增有問題麼？我覺得沒問題啊。你說呢。

#############################################################################################

1、為什麼淘寶單號這麼長？前幾年還12、13位，現在都16位了？

2、為什麼自己的淘寶單號最後4位都一樣呢？這4位數字代表什麼？

3、凡客單號是日期+訂單量嗎？

4、從訂單號可以推算出競品的銷量嗎？

5、從訂單號可以判斷出競品業務發展的速度嗎？

6、從訂單號可以猜想出競品的業務策略和佈局嗎？

7、如何解決訂單號重複的問題？

8、如何解決業務發展快，訂單號長度不夠用問題？

9、客服OR物流如何快速解讀訂單號的關鍵資訊，從而提高工作效率？

10、業務變更，如果有拆單等需求，如何設計編碼來滿足業務的靈活和拓展需求？

11、編碼變長之後，如何解決資料庫的儲存和讀取效能？

從使用者體驗和資料庫優化的角度來看

1.利用資料庫主鍵值產生一個自增長的訂單號（訂單號即資料表的主鍵）

2.日期+自增長數字的訂單號（比如：2012040110235662）

3.產生隨機的訂單號(65865325365966)

4.字母+數字字串式，字母有包含特別意義，C02356652

5.訂單號無重複性；

6.如果方便客服的話，最好是“日期+自增數”樣式的訂單號，客服一看便知道訂單是否在退貨保障期限內容；

7.訂單號長度儘量保持短（10位以內），方便使用者，尤其電話投訴時，長的號碼報錯機率高，影響客服效率；

8.訂單號儘量保持數字型(純整數)，在資料庫訂單索引查詢中，長整數字型的資料索引與檢索效率，遠遠高於文字型，因此儘量避免“字母+數字字串式”！

作者：筆記Bang 連結：https://www.jianshu.com/p/544ab3d60e77 來源：簡書 簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。