Mycat範圍求模分片
講解Myat範圍求模分片規則之前，讓我們先看如下這樣的一個系統的特徵：
比如一個系統，具備如下特點：
1）門店數量增長快，各集團內門店數量分佈不均勻。
2）業務為統計類業務，都是基於某一段時間內，然後對某一集團內的門店進行資料統計。
3）資料規模較大，以一個集團，500個門店，主表，每天1000條資料計算的話，一天是50萬條，一個月就是150萬條資料。半年單表資料量為900萬條。由於分為淡 旺季，故連續半年的資料量，不會超過1000萬條資料。
結合系統的特點，提出如下兩個重要觀點。
1）該系統的組織結構涉及集團與門店兩個層級，當然不排除集團下面還有集團，在我認為，集團下面的集團，與門店概念一致，總的說來，就是頂層集團---》門店概念。個人認為，集團與集團的資料最好應該做到邏輯、物理的隔離性。
2）資料庫分片的目的，就是要將資料較為均勻的分配到不同的節點，將查詢請求分散到多個節點執行，然後匯聚，充分利用多臺Mysql伺服器（CPU）的運算能力提高查詢的效率；同時既然需要分片，說明單庫的資料量肯定不少，未來的擴容必不可少。
根據上文提到的兩個重要觀點，現提出如下解決方案：
1）儘量做到邏輯，物理的相對隔離。我建議按照集團來組織資料，可以為每個集團，單獨建立一個數據庫使用者，然後再在該使用者下建立資料庫(也就是scheme)，這裡的schema也就是後面Mycat分片中的DataNode。這樣儲存主要基於如下幾點考慮：
a) 管理方便，如果是一個使用者的話，會看到很多的邏輯schema。
b) 每個門店的規模、特點相差太多，統一管理需要考慮太多的要素，不如分而治之，根據不同的集團，制定不同的分庫，儲存規則，靈活性較大，適應變化的需求的 能力較強。
2）根據這個系統的特點，每個集團下的資料分片，考慮的應該就是資料分佈均勻，增加分片後，資料遷移是考慮的重點，並且該系統的資料具有時效性，系統關心的資料 基本上以1年為週期，1年前的資料可以當成是歷史資料，不佔用該系統的資料庫資源。所以，我推薦資料庫分片採用【範圍求模分片】。
接下來闡述一下範圍求模分片：
分片欄位，表的主鍵如果是是Long型別的話，可以直接用主鍵ID,如不是Long型別的話，可以增加一個欄位，名字為 dcol,取建立時間的Long值。下面我重點闡述一下範圍求模分片的思想。
1）分片分組思想
2）範圍分片，兼顧了範圍查詢。
該分片方法，有個非常大的優勢，就是對擴容，原資料無需遷移，具體分片方法如下：
首先先貼上Mycat官方給出的配置資訊：
<tableRule name="auto-sharding-rang-mod">
<rule>
<columns>dcol</columns>
<algorithm>rang-mod</algorithm>
</rule>
</tableRule>
<function name="rang-mod"class="io.mycat.route.function.PartitionByRangeMod">
<propertyname="mapFile">partition-range-mod.txt</property>
<propertyname="defaultNode">0</property>
</function>
partition-range-mod.txt 檔案中的內容：
# 1451577600000 是 2016-01-01 00:00:00 的long值
# 1467302399000 是 2016-06-30 23:59:59 的long值
# 1483199999000 是 2016-12-31 26:59:59 的long值
1451577600000-1467302399000=2
1467302399001-1483199999000=2
上面的一個條目[1451577600000-1467302399000=2]代表一個分片組，開始範圍--結束範圍=該分片組有多少個分片(DataNode)。也就是我給出的方案是，2016上半年的資料存入分片組1，分片組1包含（dn1,dn2）兩個節點，2016年下半年的資料，存入分片組2,（dn3,dn4），那2017年的資料怎麼辦呢，我們可以增加分片組來實現，也可修改配置檔案，使用原來的1,2,3,4這樣來配置，實現擴容時，不需要對原資料進行遷移。
範圍求模分片，主要是要根據資料量，規劃一下單個分片組的分片數量；採用Mysql資料庫，主表的資料單個分片資料保持在500萬--1000萬條資料，關聯表（1對多）字表資料儘量保證在（1000萬）的規模，在這樣的資料集下，結合Mysql索引是可以達到效能上的要求。