單表數據量達到1000W以後，就要拆了.
背景情況
用戶表達到了 幾千萬級別，在做很多操作都比較吃力,.所以，考慮對其進行分表.
常用的切分方案
數據的切分（Sharding）根據其切分規則的類型，可以分爲兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之爲數據的垂直（縱向）切分；另外一種則是根據表中的數據的邏輯關係，將同一個表中的數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之爲數據的水平（橫向）切分。
垂直切分
即業務切分
下面來分析下垂直切分的優缺點：
優點：
拆分後業務清晰，拆分規則明確。
系統之間整合或擴展容易。
數據維護簡單。
缺點：
部分業務表無法 join，只能通過接口方式解決，提高了系統複雜度。
受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。
事務處理複雜。
由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與存儲瓶
頸，所以就需要水平拆分來做解決。
水平切分
相對於垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中
包含一部分數據。簡單來說，我們可以將數據的水平切分理解爲是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中
幾種典型的分片規則包括：
按照用戶 ID 求模，將數據分散到不同的數據庫，具有相同數據用戶的數據都被分散到一個庫中。
按照日期，將不同月甚至日的數據分散到不同的庫中。
按照某個特定的字段求摸，或者根據特定範圍段分散到不同的庫中。
如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用用戶 ID 求模舉例：
優點：
拆分規則抽象好，join 操作基本可以數據庫做。
不存在單庫大數據，高併發的性能瓶頸。
應用端改造較少。
提高了系統的穩定性跟負載能力。
缺點：
拆分規則難以抽象。
分片事務一致性難以解決。
數據多次擴展難度跟維護量極大。
跨庫 join 性能較差。
切分共同的問題
前面講了垂直切分跟水平切分的不同跟優缺點，會發現每種切分方式都有缺點，但共同的特點缺點有：
引入分佈式事務的問題。
跨節點 Join 的問題。
跨節點合併排序分頁問題。
多數據源管理問題。
一般來講業務存在着複雜 join 的場景是難以切分的，往往業務獨立的易於切分。如何切分，切分到何種程度是考驗技術架構的一個難題。
切分的一些原則
由於數據切分後數據 Join 的難度在此也分享一下數據切分的經驗：
第一原則：能不切分儘量不要切分。
第二原則：如果要切分一定要選擇合適的切分規則，提前規劃好。
第三原則：數據切分儘量通過數據冗餘或表分組（Table Group）來降低跨庫 Join 的可能。
第四原則：由於數據庫中間件對數據 Join 實現的優劣難以把握，而且實現高性能難度極大，業務讀取儘量
少使用多表 Join。
數據庫的切分引申的 數據源管理思考
主要有兩種思路：
A. 客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個數據
庫，在模塊內完成數據的整合；
B. 通過中間代理層來統一管理所有的數據源，後端數據庫集羣對前端應用程序透明；
可能 90%以上的人在面對上面這兩種解決思路的時候都會傾向於選擇第二種，尤其是系統不斷變得龐大複雜
的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴展性來說，是非常有幫助的。
中間件
爲了減少業務人員的壓力，
常用一些中間件，如 mycat Cobar
其結構大約如下圖
中間件的直接感受
這裏 簡單試用了下，mycat ，使用的例子是其官方例子
過程：
mysql 新建三個庫db1,db2,db3
在linux服務器上 安裝mycat. 配置好mycat對三個庫，表的對應，mycat的rules 等.
後續使用時，將mycat 當作mysql來使用即可，
insert 三條數據進 mycat 的 TESTDB 的 travelrecord 表,
結果如下：
三條數據的實際存儲位置在db1,db2,db3中
參考資料
https://github.com/MyCATApache/Mycat-Server/wiki/3.0-Mycat%E9%85%8D%E7%BD%AE%E5%85%A5%E9%97%A8
http://www.cnblogs.com/ivictor/p/5111495.html
http://www.mycat.org.cn/