淘寶訂單編號能查什麽(淘寶查訂單編號查詢)

很多朋友想了解關於淘寶訂單編號能查什麽的一些資料信息，下麵是(揚升資訊www.balincan8.com)小編整理的與淘寶訂單編號能查什麽相關的內容分享給大家，一起來看看吧。

id 列

首先說 id 列一般作為主鍵，沒有什麽業務含義，設計的目的是為了查詢和索引方便，如果用單表的情況下一般會設置為自增，有序了以後，無論數據庫還是業務檢索起來效率都非常高。

在分布式場景中，單表已經不能滿足我們的需求了，所以用自增 id 的方案也就不合適了。當比如我們進行分表設計時，主鍵列到底如何生成就成了一個問題，流行的方法是利用像 snowflake 這樣的算法計算出一個趨勢有序的值作為 id。（當然還有其他多種方法）這樣就滿足了擴展和一定程度上解決了檢索能的問題。

訂單號

訂單號的生成一般有相應的規則，而這些規則是各自產品根據自己情況自行設計的結果。

舉幾個例子

京東的：

京東 2013 年的訂單號 ： 479000238京東 2014 年的訂單號 ： 7783813454京東 2018 年的訂單號 ： 81467423041京東 2020 年的訂單號 ： 132971864529

淘寶的：

淘寶 2012 年的訂單號 ： 230447522918072淘寶 2016 年的訂單號 ： 2131062693288072淘寶 2019 年的訂單號 ： 329062467847108072淘寶 2021 年的訂單號 ： 2075316735066108072

可以看到京東和淘寶的訂單號都是在遞增的，而且淘寶的看起來是有規律的，這個查了一下有說從 2017 年淘寶升級了訂單，原先是用訂單號後 4 位識別用戶，2017 年以後改為用後 6 位了。

“

那麽淘寶訂單編號後 6 位用戶 id 後 6 位的目的是什麽？

翻遍了百度、知乎，沒有找到答案。

我是偶然間翻到一份淘寶技術演變 PPT，看到訂單表分庫的邏輯時才恍然大悟。

一般的平台型電商，訂單量大，為保證查詢檢索速度，都會采用分庫的形式，將巨量的訂單信息分庫存儲，一般情況下訂單係統同時維護了一個訂單號和 userid 的關聯關係，先根據訂單號查到 userid，再根據 userid 確定分表進而查詢得到內容。而淘寶在訂單號上下功夫，通過訂單號後 6 位直接鎖定庫表，大大提升高並發下的係統查詢能。

從這個策略我們也可以看到淘寶用戶訂單庫是按照用戶 id 後 6 位存儲的，例如：XXXX452154 格式的用戶訂單都是儲存在一個分庫中。

”

我通過查詢發現自己的淘寶 id 後 6 位是 107280，而我的訂單號後 6 位是 108072，還是有規律的。

找到了一個淘寶 2012 年的 PPT，可能 12 年之前的設計又不一樣。

訂單號生成規則

不重複 顯然，這種具有唯一標識的號碼是不能重複的

安全 不能被人為的猜測或推測出來

易識別 易識別就代表位數不要太長，位數控製好了就容易查詢檢索，占用空間小。

幾種常見的規則

年月日+自增長數字的訂單號（比如：2012040110235662）字母+數字字符串式，字母有包含特別意義，C02356652Snowflake 算法生成年月日+機構編碼+後四位隨機訂單號可不可以作主鍵 id 列

前提是你根據你自己設計或選擇的訂單號規則生成了一個可行的訂單號，這種情況下，如果你的訂單號包含字母等字符串那麽是不合適作主鍵的。雖然唯一，但索引查詢能較差。不過可以做唯一索引。

如果訂單號是純數字呢？

也不建議，數字當然有它的優點，能好（位數長了也不好），但是訂單號畢竟是跟業務相關的，與業務相關的列作主鍵本身可能會有問題。

假如未來的一天我們要改變業務含義，也許想把數字改字母，加幾位或少幾位，那麽就必須修改主鍵了，核心數據表的主鍵修改，可是牽一發而動全身的，會造成極大的維護開銷。

雖然直觀上感覺“多了一列”，但並不是無用的，對未來的擴展會有很大幫助。綜上，回答我們標題的問題：“訂單號和 id 列可不可以是同一列？” 或者說訂單號可不可以作主鍵，我認為可以，但不適合，所以建議不要用訂單號做主鍵。用與業務無關的 id 列作主鍵比較合適。

主鍵列怎麽設置？

如果是單表，當然是用自增 id, 如果考慮到分庫分表，可以采用像 snowflake 這樣的生成方案。

參考https://www.zhihu.com/question/19805896http://www.woshipm.com/pd/3742068.html

本文到此結束，希望對大家有所幫助呢。