原文鏈接：https://www.cnblogs.com/wangtao_20/p/7115962.html
一、兩種方案分庫分表
一般業界，對訂單數據的分庫分表，筆者了解，有兩類思路：按照訂單號來切分、按照用戶id來切分。
方案一、按照訂單號來做hash分散訂單數據
把訂單號看作是一個字符串，做hash，分散到多個服務器去。
具體到哪個庫、哪個表存儲數據呢？訂單號里面的數字來記錄着。
現在的微信紅包。它的訂單分庫分表，是對訂單號進行hash計算。不是什么取模、取整數。這樣數據是均勻分散的。
然后訂單號的末尾3個數，里面是包含了庫名稱、表名稱的。
如果要查詢某用戶的所有訂單呢？
由於是根據訂單號來分散數據的。他的訂單分散在了多個庫、多個表中。
總不能去所有的庫，所有的表掃描吧。這樣效率很低。
其實按照uid切分訂單，一樣會遇到查詢的問題。比如要查詢a訂單的信息。分庫分表的規則是按照uid，都不知道數據在哪個庫，無從查。
后續說明解決思路。
一般使用方案二的比較多，一個用戶的所有訂單，都在一張表里面，那么做分頁展示的時候，就容易。
方案二、按照用戶id打散訂單數據。
以uid來切分數據，有兩種思路：
一種是，某個范圍的uid訂單到哪些庫。0到2千萬uid，對應的訂單數據到a庫、a表。2千萬到4千萬對應的訂單到b庫。
為什么這種方案用得比較少呢？
容易出現瓶頸嗎。某個范圍內的用戶，下單量比較多，那么造成這個庫的壓力特別大。其他庫卻沒什么壓力。
第二種是，使用uid取模運算。第二種方案業界用得比較多。
一方面、處理簡單，程序上做取模運算就好了。
另一方面、使用取模的方式，數據比較均勻分散到多個庫去了。不容易出現單個庫性能瓶頸。
但是不好處也有：即要擴容的時候，比較麻煩。就需要遷移數據了。
要擴容的時候，為了減少遷移的數據量，一般擴容是以倍數的形式增加。比如原來是8個庫，擴容的時候，就要增加到16個庫，再次擴容，就增加到32個庫。這樣遷移的數據量，就小很多了。這個問題不算很大問題，畢竟一次擴容，可以保證比較長的時間，而且使用倍數增加的方式，已經減少了數據遷移量。
下面筆者，分析一下按照用戶id取模的方式分庫分表。
按照用戶id作為key來切分訂單數據，具體如下：
1、 庫名稱定位：用戶id末尾4位 Mod 32。
Mod表示除以一個數后，取余下的數。比如除以32后，余下8，余數就是8。
代碼符號是用%表示：15%4=3。
2、表名稱定位：（用戶id末尾4位 Dev 32） Mod 32。
Dev表示除以一個數，取結果的整數。比如得到結果是25.6，取整就是25。
代碼用/來表示：$get_int = floor(15/4)。15除以4，是一個小數3.75，向下取整就是3。一定是向下取整，向上取整就變成了4了。
按照上面的規則：總共可以表示多少張表呢？32個庫*每個庫32個表=1024張表。如果想表的數量小，就把32改小一些。
上面是用計算機術語來表示， 下面用通俗的話描述。
1、庫名稱計算
用戶id的后4位數，取32的模(取模就是除以這個數后，余多少)。余下的數，是0-31之間。
這樣可以表示從0-31之間，總共32個數字。用這個32個數字代表着32個庫名稱：order_db_0、order_db_2.........................order_db_31
2、表名稱計算
最后要存儲定到哪個表名里面去呢？
用戶id的最后4位數，除以32，取整數。將整數除以32，得到余數，能夠表示從0-31之間32個數字，表示表名稱。
表名稱類似這樣：order_tb_1、order_tb_2..........................order_tb_31。一個庫里面，總共32個表名稱。
比如用戶id：19408064，用最后4位數字8064除以32，得到是251.9，取它的整數是251。
接着將251除以32，取余數，余數為27。
為了保持性能，每張表的數據量要控制。單表可以維持在一千萬-5千萬行的數據。1024*一千萬。哇，可以表示很多數據了。
三、思考優點和缺點
優點
訂單水平分庫分表，為什么要按照用戶id來切分呢？
好處：查詢指定用戶的所有訂單，避免了跨庫跨表查詢。
因為，根據一個用戶的id來計算節點，用戶的id是規定不變的，那么計算出的值永遠是固定的(x庫的x表)
那么保存訂單的時候，a用戶的所有訂單，都是在x庫x表里面。需要查詢a用戶所有訂單時，就不用進行跨庫、跨表去查詢了。
缺點
這種方式也不是沒有缺點。
缺點在於：數據分散不均勻，某些表的數據量特別大，某些表的數據量很小。因為某些用戶下單量多，打個比方，1000-2000這個范圍內的用戶，下單特別多，
而他們的id根據計算規則，都是分到了x庫x表。造成這個表的數據量大，單表的數據量撐到極限后，咋辦呢?
總結一下：每種分庫分表方案也不是十全十美，都是有利有弊的。目前來說，這種使用用戶id來切分訂單數據的方案，還是被大部分公司給使用。實際效果還不錯。程序員省事，至於數據量暴漲，以后再說呢。畢竟公司業務發展到什么程度，不知道的，項目存活期多久，未來不確定。先扛住再說。
比較好的方案是不是：又能均勻分散、又能避免單表數據量暴漲方便擴容。以前看過一篇文章介紹過使用節點來存儲分庫分表。筆者暫時沒完整的思路。
二、查詢需求的考慮
方案一的查詢問題
方案一的情況下，由於是按照訂單號做分散數據到多個庫、多個表。如果需要查詢a用戶的所有訂單，咋辦？需要跨庫、跨表查詢。
這樣效率低。不可行。
方案二的查詢問題
如果是按照uid來切分訂單數據，在實際應用中一些很頻繁的查詢需求像下面這樣：
1、后台、前台，往往是輸入一個訂單號，查詢這個訂單的數據。select操作
2、然后修改這個訂單的相關狀態。update操作。
由於是，按照用戶編號將訂單數據分散在各個庫、各個表中。
那輸入訂單號，怎么知道去哪個庫、哪個表查詢呢？不可能所有的庫、所有表都查詢一遍，效率太低，不可行。
三、解決辦法：建立用戶id和訂單號的索引關系表
無論是根據用戶id來切分訂單，還是根據訂單號切分數據。總不能十全十美的。
寫到這里，發現真的沒有一種技術方案是十全十美的，看，使用用戶id來切分訂單，好處是有了，壞處也出來了。
不過沒關系，早要有心里承受：不要覺得技術是完美無缺的。針對這種情況，想辦法去解決辦法。
思路：既然是根據訂單號分散訂單數據，如果需要知道某個用戶所有的訂單。只要我能知道了a用戶的所有的訂單號，那么就可以根據訂單號定位到表名稱了。
思路：既然是根據用戶id來分散訂單數據的。那么只要知道了這個訂單號是誰的(得到了用戶id)，就能知道去哪個庫、哪個表查詢數據了。
那怎么知道是誰的呢？建立一個索引關系表，暫且叫做訂單用戶關系索引表order_user_idx。咱們命名為了保持維護性，還是一看能夠知道是干嘛用的。
存儲的數據包括兩項：訂單號、用戶編號。
這樣輸入訂單號，可以去查詢索引關系表，獲取到用戶編號。
得到了用戶編號，問題解決了。訂單信息是根據用戶編號分庫分表的，可以直接定位到x庫x表了。
當創建訂單的時候，就要把關系插入到表里面去了。保存關系記錄時，為了減低用戶等待時間，不需要實時，做成異步。加入到消息隊列中去操作。
訂單用戶索引關系表的性能優化
考慮到，一個用戶的下的訂單可能是幾十個，也可能是幾百個，隨着時間的推移，會越來越多。這個索引關系表，也不能使用單表存儲。
所以對這個訂單用戶關系索引表，也要進行分庫分表：直接根據訂單號取模進行分庫分表。是不是感覺挺麻煩了。確實麻煩。不過能解決問題就好。暫時沒想到其他辦法了。
一個訂單，在創建的時候，就已經分配好給指定用戶了。只是一個關系對應，以后也不會變化。
根據這個特點。訂單用戶索引關系表，其實可以放到內存中緩存起來應對查詢需求(數據庫那張索引關系表也要有，數據要持久化)。
平時查詢的時候，走內存緩存查詢。如果查詢不到，再走數據庫查詢一下關系。這樣速度就很快了。
結語：水平分表，其實折騰起來工作量挺大的，切分了后，出現新的問題，代碼查詢又得改，要提供其他解決辦法。所以經常看到別人說，能不水平分表，盡量不要分，業務沒達到瓶頸，先用硬件扛住，后面再考慮水平切分數據。看銀行、聯通這些有錢的企業，使用性能強勁的oracle搭配小型機服務器，單表的數據量達到十多億。小型機是專門定制的，幾十萬一台。性能很強。分庫分表是很耗費時間、當你交易量做到上億規模的時候，那時，公司的實力應該可以了，經濟方面有足夠的實力聘請經驗豐富的技術來重構。
思考一、b2b平台的訂單分賣家和買家的時候，選擇什么字段來分庫分表呢？
上面討論的情況是，b2c平台。訂單的賣家就一個，就是平台自己。
b2b平台，上面支持開店，買家和賣家都要能夠登陸看到自己的訂單。
先來看看，分表使用買家id分庫分表和根據賣家id分庫分表，兩種辦法出現的問題
如果按買家id來分庫分表。有賣家的商品，會有n個用戶購買，他所有的訂單，會分散到多個庫多個表中去了，賣家查詢自己的所有訂單，跨庫、跨表掃描，性能低下。
如果按賣家id分庫分表。買家會在n個店鋪下單。訂單就會分散在多個庫、多個表中。買家查詢自己所有訂單，同樣要去所有的庫、所有的表搜索，性能低下。
所以，無論是按照買家id切分訂單表，還是按照賣家id切分訂單表。兩邊都不討好。
淘寶的做法是拆分買家庫和賣家庫，也就是兩個庫：買家庫、賣家庫。
買家庫，按照用戶的id來分庫分表。賣家庫，按照賣家的id來分庫分表。
實際上是通過數據冗余解決的：一個訂單，在買家庫里面有，在賣家庫里面也存儲了一份。下訂單的時候，要寫兩份數據。先把訂單寫入買家庫里面去，然后通過消息中間件來同步訂單數據到賣家庫里面去。
買家庫的訂單a修改了后，要發異步消息，通知到賣家庫去，更改狀態。
思考二：那可以按訂單號來分庫分表嗎?
這樣分庫分表的話，用戶有10個訂單，訂單不見得都在一個庫、一個表里面。查詢a用戶的所有訂單，就會變得麻煩了。尤其是要進行分頁展示，分散在不同的表，甚至不同的數據庫服務器，也比較耗費性能。
那么訂單號里面，最好是要有分庫分表信息。淘寶的是在訂單號里面添加了賣家id末2位、買家id末2位。這樣的好處是干嘛呢？直接定位到具體的庫、具體的表去了？
怎么根據這個呢。因為分庫、分表的規則，買家庫是按照賣家id末尾2位數分，賣家庫是按照賣家id末尾兩位分。
所以，只要從訂單號里面拿到了這些數字信息，就知道在哪個庫，哪個表了。
這種辦法，與微信的紅包訂單號是類似的，末尾三位數包含了庫信息、表信息。
按照這樣，其實就沒必要使用訂單號來計算了？
如果是按照用戶id的后4位數取模分散訂單數據。那么訂單號的生成，可以在后面加上用戶id的后4位數。
那么，雖然是按照用戶id來對訂單表分庫分表的。其實可以直接根據訂單號，知道這個訂單在哪個庫哪個表了。
如果是b2b系統，涉及到賣家和買家。那么可以把賣家和買家的id后面4位都加進去。不過是不是訂單號太長了？
思考三、按照訂單的時間來分表如何?
一月一張表。一年一張表。用戶的所有訂單，會分散在不同的庫、不同的表中。
按照時間分，在切分訂單數據的時候，業界用得比較少。
出現如下兩個問題：
1、如果需要分頁查詢某個用戶的所有訂單數據，就會出現跨庫、跨表查詢。效率低。
可以做折中：限制只能查一個范圍內的訂單，比如一次只能查詢，一年以內或者一個月以內的訂單。
2、某個時間集中寫入數據，出現瓶頸。如一個月一張表。這個月的訂單量暴漲呢。那么寫入新的訂單數據都會操作這張表。造成性能低下。影響整個業務系統交易。
真正好的分表方案，盡量將寫數據分散到多個表去，達到分流效果，系統的並發能力就提高了。